Custom software
Build or buy, before you commit either way
By the time build or buy reaches a meeting, somebody usually has a preference and the meeting exists to ratify it. These are the questions that settle it honestly in an afternoon, including the ones that argue against writing custom software at all.
Key takeaways
- Build when the process is what makes you money, or when nothing on the market models it. Buy for everything else.
- Compare the full five-year cost on both sides: licences, customisation and configuration drift against build, ownership, documentation and staffing.
- The wrong reason to build is to avoid changing a habit. That is the most expensive requirement anyone writes down.
- Extending a platform you already own is a third answer, and it is frequently the right one.
- If the answer is buy, the remaining work is integration and process design, which is where most of the value was anyway.
Build or buy tends to arrive at a meeting already decided. Someone has a preference, formed for reasons that are often perfectly sound, and the meeting exists to ratify it. The debate that follows is about vendors and estimates, and it feels rigorous, but the actual decision was made before anyone sat down.
The useful version of this conversation takes about an afternoon and turns on a small number of questions. Most of them are unglamorous, and several of them argue against writing custom software, which is a reasonable thing for a firm that writes custom software to say out loud.
The question underneath the question
Start here: is this process one of the things that makes you money, or is it a thing you have to do because everyone in your industry has to do it?
Payroll, general ledger, email, document storage and expense claims are not where anyone wins. They are solved, and solved well, by products that thousands of organisations have already pushed on. Building your own version buys you a slightly better fit and a permanent maintenance obligation on something that was never going to differentiate you.
The processes worth building for are the ones a competitor could not copy from your website: the pricing logic that reflects twenty years of knowing which jobs go wrong, the assessment sequence that lets you answer a client in a day when the market takes a week, the operational sequence that is genuinely yours. When the process is the product, a platform that forces you into its shape is quietly removing the thing you are selling.
Six questions that settle it
Once the differentiation question is answered, six more usually finish the job. They can be answered in a workshop, and the answers should be written down, because the value is partly in having them on record when the decision is questioned in a year.
- 01Does something on the market already do seventy per cent of this? If yes, the honest comparison is configuration effort against build effort, not feature list against feature list.
- 02What does the customisation actually cost? A product that fits after six months of professional services and a permanent consultant relationship is not the cheap option it looked like in the quote.
- 03How many people will use it, and for how many hours a day? Per-seat pricing at fifteen users is background noise. At four hundred it is the dominant term in the five-year number.
- 04Who owns the data and can you get it back? Ask for the export format before you sign, not after you want to leave.
- 05What happens when your process changes? Products change on the vendor's roadmap. Custom software changes when you decide it should, and that difference is worth real money in a process that moves.
- 06Who maintains it in year three? For a build, name the person or the arrangement. If nobody can be named, you are choosing a maintenance problem, whatever the business case says.
The costs each side tends to forget
Both options are routinely presented at their most flattering. Buying is quoted as licence cost, and building is quoted as build cost, and both numbers are the smallest honest figure available.
| Buying tends to under-count | Building tends to under-count |
|---|---|
| Implementation and professional services to make it fit | Ownership for the full life of the software, not the build window |
| Per-seat growth as headcount grows | Documentation good enough for a team that is not the original one |
| The workarounds staff invent for what it cannot do | The exceptions and edge cases the old process quietly handled |
| Integration into the systems it has to talk to | Integration into the systems it has to talk to |
| Renegotiation leverage you no longer have once the data is inside | A named support path, and someone answering when it breaks |
The last row on the buy side is worth pausing on. Switching cost is not a line item, it is a negotiating position, and it moves against you every year the platform holds more of your history.
The most expensive requirement anyone writes down
"It has to work the way we currently work." Sometimes that is a real constraint carrying regulatory or commercial weight. Often it is a habit, and building software to preserve a habit is the most expensive way to avoid a conversation.
The third answer people forget
Build or buy is presented as a binary and usually is not one. A great deal of what gets built from scratch could be a custom module, component or app extending the CRM, finance system or CMS you already pay for.
That route keeps the record in one place, inherits the platform's identity, permissions and audit trail, and avoids creating a sixth system somebody has to check and reconcile. It is less satisfying to scope than a greenfield build. It is frequently the correct answer, and we would rather configure or extend something you already own than invoice you to build it a second time.
If the answer is buy, the work is not over
A decision to buy is not a decision to stop thinking. The product arrives with a model of how the work should happen, and that model will disagree with yours in a handful of specific places. Those places are where the value leaks: the manual bridge, the parallel spreadsheet, the step that exists only because two systems will not talk.
So the remaining work is integration and process design, and it is usually where most of the benefit actually was. A bought platform that nobody integrated is how organisations end up with six systems and fifteen connections between them.
The rule we work to
Custom is the right answer when the process is what makes you money, or when nothing on the market models it. It is the wrong answer when it is being used to avoid changing a habit.
The short version
Ask whether the process differentiates you. Compare five-year totals rather than the two headline numbers. Check whether extending something you already own does the job. Name who maintains it in year three before you commit. And be willing to reach the answer that says buy, because it is the right one more often than a development firm's incentives would suggest.
Common questions
When should you build custom software instead of buying a product?
Build when the process is one of the things that makes you money, or when nothing on the market models it without heavy customisation. Buy for the processes every organisation in your industry runs the same way, such as payroll, ledger, email and document storage, where a product has already been refined by thousands of customers.
How do you compare the cost of building against buying?
Compare five-year totals rather than headline figures. On the buy side include implementation, per-seat growth, integration and the workarounds staff invent. On the build side include ownership for the full life of the software, documentation for a team that is not the original one, integration, and a named support path.
What is a bad reason to build custom software?
Preserving how you currently work when the current way is a habit rather than a constraint. Building software to avoid changing a habit locks the habit in permanently and charges you for the privilege. Regulatory or commercial constraints are different, and those are worth building around.
Is there an option between building and buying?
Yes, and it is often the right one. Extending a platform you already pay for with a custom module, component or app keeps the record in one place and inherits the platform's identity, permissions and audit trail, instead of creating another system to reconcile against.
Who owns the code if you build custom software?
In our engagements, you do. Code lives in your source control from the first commit, on a mainstream stack another team could pick up, deployed into your own cloud accounts, with documented handover written for a team that is not us.
Read next
Why the guardrails are the expensive part of an AI agent
Getting a model to read a document well is the afternoon. What makes it safe to run unattended is everything around it, and that work costs the same whether the agent is for one client or fifty. Which is precisely why it keeps getting skipped.
Governance decisions that are cheap on day one
Nobody books a governance workshop. It arrives later as a question from an auditor, a client security review or a privacy complaint. Four decisions cost close to nothing at the start and a great deal once there is data in the system.