"Should we build custom software or buy something off the shelf?" is the wrong question, and it is the one almost every company asks first. The right question is narrower and much easier to answer: which parts of what we do are actually unusual?
Most businesses, honestly examined, are ordinary in about ninety per cent of their operations and genuinely unusual in the rest. Accounting is accounting. Payroll is payroll. Email is email. But the thing that makes you money — the way you price, the way you schedule, the sequence your product moves through, the compliance step your competitors do manually — that part is often specific enough that no product fits it without compromise.
Custom software earns its cost in that last ten per cent. Spent anywhere else, it is an expensive way to get something you could have subscribed to.
Four signs you have outgrown the product you bought
The usual trigger for a custom build is not a strategic decision. It is accumulated friction. These are the patterns worth taking seriously:
The spreadsheet that runs alongside the system
Somebody maintains a spreadsheet that holds the real state of things, because the system cannot represent it. Every month it gets reconciled by hand. That spreadsheet is a specification, and it is telling you exactly what is missing. It is also a risk: it usually lives on one person's machine and only they understand the formulas.
You are paying for seats to do data entry
When a chunk of your headcount exists to retype information from one system into another, you are paying salaries to work around a missing integration. Over three years that is frequently more than the integration would have cost to build.
The product's model does not match yours
You sell in a unit the software does not have. Your approval process has a step the workflow engine cannot express. You have two customer types that behave completely differently and the system only knows one. Every workaround for this is a small permanent tax, paid by whoever is unlucky enough to be using the system that day.
Your licence cost scales with something you cannot control
Per-seat pricing is fine until headcount grows. Per-transaction pricing is fine until volume does. If your software bill grows in step with the thing you are trying to grow, you have a structural problem that negotiating a discount only postpones.
One of these on its own is usually not enough. Two or three together, sustained over a year, generally is.
The cost nobody quotes for
Build quotes cover building. The bill does not stop there, and the honest version of the total looks roughly like this:
| Cost | What it actually is |
|---|
| The build | Design, development, testing, deployment. The only part most quotes describe. |
| Hosting and services | Servers, database, storage, backups, email delivery, certificates, any third-party API you call. Small monthly, permanent. |
| Keeping it current | Frameworks, runtimes and libraries reach end of support on somebody else's schedule. Ignoring this for three years turns a routine upgrade into a rebuild. |
| Changes | Your business changes, so the software has to. Budget for it as an ongoing line, not as a series of surprises. |
| Someone who knows how it works | The real one. Either you retain the people who built it, or you pay a new team to learn it. Documentation reduces this cost; it does not remove it. |
A reasonable planning assumption for ongoing cost is a meaningful fraction of the original build each year, spread across those last three rows. If a proposal does not mention any of it, that is not because it does not apply.
A build order that survives contact with reality
Most custom projects that go badly do so in a recognisable way: too much was specified up front, nothing was usable until the end, and the first real feedback arrived after the budget was committed. The order below is deliberately boring, and it avoids that.
Start with the thing that hurts
Not the whole system. The single worst part of the current process — the spreadsheet, the double entry, the report that takes two days. Build that, put it in front of the people who do the job, and watch them use it. You will learn more in that first week than in two months of requirements workshops.
Make the data model the thing you argue about
Screens are cheap to change. Database schemas are not, and every wrong assumption baked into one propagates outward for years. Spend the disproportionate effort here, early, with the people who actually know the edge cases. "Can a job have two customers?" is the kind of question that costs an afternoon now and three weeks in eighteen months.
Integrate early, not last
Whatever has to talk to your accounting system, your warehouse, your payment provider — do the hard one first. Integrations are where estimates go wrong, and finding that out in month one is survivable.
Ship in pieces people can use
Every increment should leave someone better off than before. This is partly about momentum, but mostly it is about evidence: software people are actually using generates real feedback, and real feedback is the only reliable correction to a wrong assumption.
When not to build
A development company telling you when not to hire a development company sounds like a trick, but the projects that go wrong are expensive for everyone involved, and most of them were visible in advance. Do not build custom when:
- The process is not defined. If three people describe the workflow three different ways, software will not settle the argument — it will encode whichever version was in the room on the day. Sort the process out first, on paper.
- The real problem is a product nobody was trained on. Plenty of "the system can't do it" turns out to be "nobody showed us the module". Worth half a day of checking before spending six figures.
- A product does ninety per cent and you can live with the ten. Adapting your process to decent software is often cheaper and faster than adapting software to your process, especially for things that are not a competitive advantage.
- Nobody internal will own it. Custom software needs someone on your side who makes decisions and holds the roadmap. Without that, it drifts, and the vendor ends up guessing.
- The timeline is driven by a date rather than a scope. Fixed date plus fixed scope plus fixed budget is three constraints and you can have two. Pretending otherwise just moves the failure later.
What to ask for in a proposal
Beyond the price, the things that separate a proposal you can act on from one you cannot:
- The assumptions, written down. Every estimate rests on some. A proposal that lists them is one you can check; one that does not is a number with nothing behind it.
- Who owns the code and the infrastructure. Accounts in your name, repository under your control, from day one. This is not a sign of distrust — it is what makes changing your mind possible later.
- What phase one leaves you with if you stop there. If the answer is "nothing usable", the phases are drawn wrong.
- How changes are handled. Scope will change. The question is whether there is a defined, unsurprising way to price and schedule that, or whether each one becomes a negotiation.
- Who is actually doing the work. Names and availability, not a capability deck.
If you are working through whether a build is justified at all, that is a conversation worth having before anyone writes a proposal. Tell us what the spreadsheet does — it is usually the fastest way to work out whether you need software or a better process.