Software Engineering
Custom software development means building a system around your business rules instead of bending your business around a product you bought. It is worth doing when the process you run is the thing that makes you competitive, and worth avoiding when an off-the-shelf tool would do the job. We will tell you which situation you are in before quoting.
What we build
Most of our work is line-of-business systems — the software a company runs on rather than the software it sells, though we build products too.
- Web applications and internal platforms, typically TypeScript with React or Next.js.
- Backend services and APIs in Node.js, Python, or Go, with PostgreSQL behind them.
- Mobile applications where a browser is genuinely not enough.
- Data pipelines and reporting where the reporting is the product.
Build versus buy
The honest test is whether the process is a differentiator or just a cost. If a competitor could buy the same capability off the shelf and be no worse off, buy it. Build when the rules are specific to how you win, when integration with what you already run is the hard part, or when licence costs at your scale exceed what building would cost.
How we keep it maintainable
The expensive part of custom software is not writing it, it is living with it. Everything we build is set up so that another team could take it over.
- Automated tests written alongside features, not retrofitted.
- Architecture decisions recorded with their reasoning, so future changes are informed.
- Boring, conventional choices unless there is a specific reason not to be.
- Deployment automated from the first release, so shipping never depends on one person.
Frequently asked questions
- How do you estimate a build?
- After discovery, not before. An estimate given before anyone has looked at your constraints is a guess with a number attached. Discovery is short and paid, and it produces a plan you can take elsewhere if you want to.
- Can you work with our existing system?
- Yes, and most of our work is exactly that. Greenfield projects are the exception. We start by reading the code and the infrastructure before proposing anything.
- What technologies do you use?
- Mainly TypeScript, Node.js, React and Next.js, Python, Go, PostgreSQL, Kubernetes, and AWS. We pick from what your team can maintain, not from what is newest.
Tell us what you are building
Send a short description of the system and the constraint you are hitting. We reply within one business day.
Book a consultation