The part of the work no product covers.
Every business has one process that runs on a shared document and a person who remembers. It is usually the process the business is built on.
Thirty minutes · no predetermined package
It already exists. It is just not software.
Nobody sets out to run an approval process in a spreadsheet. It arrives one exception at a time, and by the time anyone notices, it is load-bearing.
A shared document and a person who remembers
Six tabs, four colour conventions nobody wrote down, and one cell that everything else references.
| Client | Amount | Stage | With | Date | Notes |
|---|---|---|---|---|---|
| Meridian Fr… | 14,200 | ops ok | fin? | 12/3 | chase |
| Halewood | 6,900 | legal | me | — | ask R |
| Corvo Log… | 31,000 | ? | ? | 08/3 | 2nd sig? |
| Anders Roof | — | proc | me | 13/3 | |
| Pilar Foods | 4,100 | done | 01/3 | paid |
The same process, with a system underneath
The chain is a rule the software enforces. The exception is a state, not a colour. The history is a record.
What this looks like from inside.
Six things people say before they know what they are describing.
The workflow that makes you money is the one running outside the system.
A question arrives, and answering it means opening a spreadsheet and asking someone who was there.
An approval step happens over email, so there is no record of who approved what.
A new hire takes months to be useful, because the process is undocumented and lives in people.
A number is calculated by hand, and two people calculate it differently.
The internal tool everyone depends on is a shared document, and nobody will say which version is current.
Six questions, before anyone writes anything.
The answers decide whether this is a build at all. Most of the time they decide it is not.
Five stages, and the boundary comes first.
Draw the boundary
architecture, signedWhat is built and what stays configured, written down, because scope creep here is not a schedule risk — it is an architecture failure.
Specify the rest
the first sliceNow that the slice has taught us what was wrong in the original assumption, the remaining scope is written properly.
Build and instrument
working softwareProduct delivery with tests, logging and error reporting shipped alongside — not added when something breaks.
Cut over real data
in useMigrated against a mapping you approve, with the old system readable until you are confident.
Hand over
the runbookDocumentation, tests, runbook and access. Written for a developer who has never spoken to us.
The architecture decides the platform. Not the other way round.
Four answers, and the last one is the most common. We will tell you when it applies.
Next.js and TypeScript on managed hosting
A web application or portal where performance and hiring pool both matter.
A platform-native extension
The logic belongs beside the data, and the platform's own extensibility is genuinely sufficient.
A no-code or low-code tool
The logic is shallow and the volume is low. Recommended freely, because it is often the honest answer.
Nothing — configure instead
The requirement turns out to be expressible in the platform. This is the most common outcome.
The sector changes the intake. It does not change the method.
Technology and business services
Businesses that already run on software, where the problem is usually the seams between systems rather than any one of them.
See the sector →Industrial, logistics and distribution
Quote-to-order workflows, distributor and dealer relationships, and accounts measured in years rather than transactions.
See the sector →Construction, home and property
Estimate-driven selling where the constraint is usually scheduling and crew capacity rather than demand.
See the sector →Financial and professional services
Long consideration cycles, referral-weighted pipelines, and communication that has to satisfy a regulator as well as a buyer.
See the sector →What people ask about custom software development.
What is custom software development?
Building an application around a process that already exists, rather than reshaping the process to fit a product. In practice it starts with a boundary — what the software will own and what stays in the systems you already run. Most of the risk sits in that line rather than in the code.
How much does custom software development cost?
It scales with the number of external systems involved and the number of decisions the software has to make unattended, not with screen count or headcount. A single well-bounded internal tool is a different order of cost from something that has to stay correct across four systems that disagree. We price against a written architecture, so the figure moves only when the scope does.
How long does a custom software project take?
The boundary and the architecture take weeks and are signed off before anyone writes production code. Delivery after that is incremental, with something usable in front of real users early and extended from there. A project where nothing is usable until the end is a project that finds out it was wrong at the end.
When is custom software the wrong answer?
When a configured platform gets you to roughly the same place. A large share of what we are asked to build turns out to be a configuration complaint wearing a product name, and we will say so — recommending a build we cannot justify with a named failure is selling our own capacity.
What is the difference between custom software and off-the-shelf?
Off-the-shelf covers the common four fifths of a process well and the remaining fifth badly. Custom software exists for that remainder, which is usually the part that makes the business competitive. The right answer is frequently both, with a deliberate line drawn between them.
Who owns the code?
You do, from the first commit — the repository sits in your organisation rather than ours. Documentation and runbooks are part of the build instead of an exit deliverable, so ending an engagement is a decision rather than a risk.
What is enterprise software development?
The same work under harder constraints: systems of record that cannot be replaced, an access model that has to survive an audit, and a release process that cannot take the business down. The engineering is not more advanced — the integration surface and the failure modes are.
What does custom application development involve beyond writing code?
Deciding what is true when two systems disagree, what happens to a record when a step is skipped, and who is entitled to see it. Those decisions determine whether the application survives contact with real operations, and none of them are discovered by writing code faster.
Can you build software that integrates with systems we already run?
That is usually the job rather than an addition to it. Most internal tools are worth building precisely because they sit between systems that were never designed to speak to each other, and the integration is where the correctness problems live.
What happens after launch?
The engineers who built it keep it running, if you want that arrangement. Shipping is the middle of the job rather than the end of it.