Most companies asking "should we build custom software?" are really asking two different questions at once: is our current stack failing, and would building actually fix it. Those have different answers, and conflating them is how businesses end up with an expensive rebuild of the same problem.
What follows is the framework we use in scoping calls. It's deliberately structured so you can reach a defensible conclusion without talking to a vendor — including the conclusion that you shouldn't build.
Step one: separate a tooling problem from a process problem
Before evaluating software, check whether the underlying process is defined at all. If three people would describe your intake or handoff differently, no system will fix that — a custom build will simply encode the confusion at higher cost.
The honest test: can you draw your core operational flow on one page, with the decision points and who owns each? If not, that's the first project, and it's cheaper than any software.
Step two: score the structural signals
These are the indicators that correlate with a genuine platform ceiling rather than a bad configuration. Count how many apply:
- The central object of your business — a shift, matter, property, route, claim, engagement — has to be faked using a repurposed CRM object.
- At least one spreadsheet is load-bearing: if it were deleted tomorrow, operations would stop.
- Two or more systems hold overlapping versions of the same record and a human keeps them aligned.
- Your pricing, payroll or entitlement rules are too conditional for the platform's rules engine and are applied manually.
- You pay a consultant, partner or in-house admin primarily to maintain configuration.
- Per-seat costs have caused you to keep staff, subcontractors or clients out of the system.
- Leadership doesn't trust a report until someone has checked it against another source.
- A change you've wanted for over a year hasn't happened because the software can't accommodate it.
- Something you do better than competitors depends on staff remembering to do it, because the system can't enforce it.
Reading your score honestly
Zero to two signals: your problem is almost certainly configuration, training or process. Fix those. Building would be a very expensive way to avoid a difficult conversation.
Three to five: you're in the genuinely ambiguous zone. A targeted custom application around the one broken area — dispatch, or billing, or compliance — integrated with the platforms you keep, is usually smarter than a full replacement. Most of our first engagements start here.
Six or more: you've outgrown configuration. The workarounds are now the system, and the costs are structural rather than incidental. Continuing to buy more tools tends to add integration surface without removing the underlying mismatch.
Step three: the scale and durability test
Custom software is a multi-year asset, so the operation it models has to be stable enough to be worth modelling. Two questions decide this.
First: will the workflow you'd encode still be recognisable in three years? If your delivery model is still changing monthly because you're finding product-market fit, build later. If it's been fundamentally the same for years and the pain is that software can't keep up with it, build now.
Second: does the arithmetic work? Total your current annual cost including reconciliation labour, projected over five years at your expected headcount. Compare against a build plus maintenance. If custom isn't clearly better across that horizon, the platform is the right answer and you should stay.
Step four: capacity to be a good client
This is the factor most vendors won't raise. Custom software requires someone internally who knows how the business actually works, can make decisions, and can commit real hours during discovery and rollout. Not a committee, not a part-time delegate.
Projects fail far more often from an absent internal owner than from engineering. If nobody can be that person for the next several months, delay the project rather than starting it badly.
Legitimate reasons not to build
We turn work down for these reasons regularly, and you should apply them to yourself before anyone sells you anything:
- Your processes are standard and the platform genuinely fits — the friction is training, not architecture.
- The business model is still shifting; you'd be encoding a moving target.
- The real problem is one integration or one report, which is a far smaller project.
- There's no internal owner with the authority and time to drive it.
- The five-year cost comparison doesn't favour building at your scale.
If you do build, start narrow
A full operational platform delivered in one enormous release is the highest-risk way to do this. The approach that works is to identify the single most expensive mismatch — usually the load-bearing spreadsheet — build a system around that one area, and expand once it's proven in daily use.
That's why our process starts with analysis rather than architecture, and why the first deliverable is a scope you can say no to.
The short version
- Fix undefined processes before buying or building anything — software encodes whatever it finds.
- Six or more structural signals means you've hit a real platform ceiling; two or fewer means the problem is configuration or training.
- Custom is right when the workflow is durable, the five-year numbers favour it, and an internal owner has the time to drive the project.