Custom Software Development
An off-the-shelf product covers most of your process, and the rest runs on spreadsheets. We build that remainder properly, and write it so the next team can maintain it.
Buying is cheaper than building, and it stays cheaper right up to the point where the product covers most of your process and the rest is absorbed by spreadsheets and the people who keep them. That remainder is usually where the work you compete on lives. We build that part properly, integrate it with what you have already bought, and leave a system that can be changed for years without a rewrite.
Build the part nobody sells you
Most organisations already own a capable ERP or case-management system, and replacing it would be waste. The narrower question is which part of your process no vendor models, and what running that part by hand costs you in people and rekeying. That is the piece worth building.
- We map the process first, then draw the line where a product stops
- What you already run stays; the new system talks to it rather than replacing it
- Domain rules live in one place, not scattered through screens and stored procedures
- Work lands in releasable slices, so something useful is running early
Custom software is judged in its third year
The first release is the easy part. What decides whether a system was worth building is the change request that arrives eighteen months later, when the people who wrote it have moved on and the person reading the code has never met them. Most of what we do during the build is aimed at that moment rather than at launch day.
In practice that means boundaries drawn around the things that change together, so a pricing rule can be altered without touching invoicing. Decisions get recorded alongside the alternatives we rejected, so nobody re-litigates a settled choice from scratch. Tests that state what the business expects rather than what a function returns. A conventional stack, and no framework of our own invention for your team to learn.
What building well looks like
None of this is exotic. It is the ordinary discipline that separates a system your team can still change in year three from one they are afraid to touch.
Boundaries that match the business
Modules are drawn around the parts of your process that change at the same time, so a rule change lands in one place instead of six.
Integrated with what you own
The new system reads from and writes to the ERP, the CRM, the finance ledger and the warehouse feed you already run, so nothing is keyed in twice.
Code your own team can read
Conventional patterns on a mainstream stack, reviewed as we go. If you hire two engineers next year, they should be productive without an initiation rite.
Handover built in from the start
Runbooks, dashboards and on-call procedures ship with the system rather than being assembled in a rush at the end of the engagement.
How we choose the stack
Your existing stack usually wins. If your team runs .NET on SQL Server, that is what we write, because a system nobody in-house can maintain is a liability. Where the choice is genuinely open, we pick conventional and well supported over interesting.
- .NET
- Java
- Node.js
- Python
- TypeScript
- React
- Next.js
- PostgreSQL
- SQL Server
- Redis
- Docker
- Kubernetes
- Terraform
- GitHub Actions
How the work runs
Work happens in your repositories and your cloud accounts from the first commit, and lands in releasable slices rather than in one launch at the end. Each step below finishes with something you can look at and argue with.
- 01
Scope and shape
We sit with the people who do the work, read the systems it already touches, and write down what the software must do and what it deliberately will not. You review a scope note, a domain model and the first architecture decisions.
- 02
Thin slice
The first build is a narrow path through the whole system rather than one finished layer: a single real transaction, end to end, on your infrastructure. You get a running environment and a deployment you can click through.
- 03
Build out
From there it goes in slice by slice, each behind a code review and a test suite that states what the business expects. You see working software at the end of every iteration, in an environment your own people can use.
- 04
Cutover
Going live is rehearsed, including the part where data moves and the part where it has to move back. Runbooks and alerting are in place before the first real user arrives, and you sign off against them.
- 05
Handover
Your engineers work alongside ours through the build, not at the end of it. We finish with a walkthrough of the architecture decisions and the operational procedures, and a written account of what we would change next.
Before you commit
We start by trying to talk you out of it. Discovery looks at what the market already sells, what it would cost to change your process to fit a product, and what the gap would cost to run manually for a few years. Building wins when the gap is the thing you compete on, or when the workaround has its own headcount.
Not sure which one you need?
Describe the problem in a paragraph and we will tell you which service applies.