Services
Custom software, built to your operation
Verttical builds systems around the way a specific operation works instead of bending the operation to fit a general product. That is worth doing when the process is the advantage, and not worth doing when a product already covers it — this page is mostly about telling those two apart.
Start a conversationCustom software versus configured software
Custom software is written for one operation and shaped by its actual constraints. Configured software is a general product adapted through settings, fields and integrations until it approximates the same thing.
Configuration is faster and cheaper right up to the point where the product cannot express what the operation does. Past that point every further step is a workaround, and the accumulated workarounds become harder to maintain than the custom system would have been. The skill is recognising that point before crossing it, not after.
Build or buy
Five questions that decide it. Three or more answers in the right column usually mean building; otherwise buy the product and spend the budget on integration.
| Question | Points to buying | Points to building |
|---|---|---|
| Is the process your competitive advantage? | No, everyone does it the same way | Yes, it is how you win |
| Does a product already cover 80% of it? | Yes, out of the box | Only with heavy customisation |
| How often does the process change? | Rarely | Continuously |
| How many systems does it have to touch? | One or two, with good APIs | Several, including internal ones |
| What happens if the vendor changes course? | You can switch | You would be stranded |
What drives the cost
Cost in custom software is driven by integrations, data migration and edge cases — almost never by the number of screens. A four-screen system that reconciles three legacy databases costs more than a forty-screen system that owns its own data.
The second driver is decision latency on the client side. Development time is cheap compared to a team waiting two weeks for an answer about how a business rule should behave, and that wait is the single most common source of overrun.
The third is scope that was never written down. Discovery exists to convert assumptions into a list somebody signed, which is why the first stage of an engagement produces a plan rather than a proposal.
How delivery runs
Incremental, with something in production early. A system that only appears at the end is a system nobody validated.
01
Discovery
Two to eight weeks mapping the processes in scope, what each costs to run today, and what the system has to absorb. Output is a plan the client owns.
02
First slice in production
The narrowest end-to-end path that produces real value, running with real users. It is how assumptions get tested while changing them is still cheap.
03
Widen
More of the process, more edge cases, more integrations — each increment shipped rather than staged for a release date.
04
Keep it running
The system changes as the operation does. The fourth stage is growth, not handover.
Questions we get asked
- When is custom software worth it compared to off-the-shelf?
- When the process is a competitive advantage, when no product covers about 80% of it without heavy customisation, when the process changes continuously, when it has to touch several internal systems, or when being stranded by a vendor’s roadmap would be serious. Fewer than three of those and buying usually wins.
- What drives the cost of a custom software project?
- Integrations, data migration and edge cases — rarely the number of screens. After that, the biggest driver is how long the client side takes to answer questions about business rules, because development waiting on a decision is the most common source of overrun.
- How long does a custom software project take?
- Discovery runs two to eight weeks. After that, delivery is incremental with the first end-to-end slice in production early rather than a single release at the end, so there is no useful single number — the meaningful question is when the first slice ships.
- What is the difference between custom software and a bespoke product?
- None in practice; bespoke is the more common term in the UK and custom in the US. Both mean software written for one organisation rather than sold to many.
- Can you work with systems we already have?
- Yes, and it is the normal case. Most engagements are as much integration as new construction, because the operation already runs on something and replacing all of it at once is rarely the right risk to take.
- What do we get out of the discovery stage if we do not continue?
- A plan you can act on independently, including the measurement of what the processes in scope cost to run today. It is written to be useful to another team, not only to us.
Start with the discovery stage
Tell us what your operation does that no product handles well. We reply within one business day.
Start a conversationRelated services
- AI implementation
Agents, model integration and retrieval over your own data, with the evaluation and monitoring that keep them working after launch.
- Business process automation
We measure what a process costs to run before automating it, and say so when the answer is to leave it alone.
Last reviewed 2026-08-14