We sell custom software development. We also talk a meaningful share of enquiries out of buying it, and that is not modesty. It is that a custom system built for the wrong reason becomes a liability that outlives the problem it was meant to solve, and the client remembers who built it.
So here is the framework we actually use, including the part that costs us work.
The short version
- Buying should be the default. Somebody has already built it, tested it on thousands of businesses, and is paying a team to keep it secure. You cannot match that with a project budget.
- The build cost is not the cost. Running it is: hosting, updates, security patches, and a person who understands it, for as long as you use it. Most build-versus-buy decisions compare the wrong numbers.
- Four cases justify building: it is your actual differentiator, no product fits and the workarounds cost more, you need glue between systems you already own, or licence cost at your scale exceeds build plus run.
- The third option is usually the right one: configure and extend a platform you already pay for. Cheaper than building, more fitted than buying plain.
- If you do build, specify the boring parts (ownership, handover, documentation, who runs it) before the interesting parts.
Why buying should be the default
A mature product has absorbed costs you will otherwise pay yourself:
- Thousands of customers have already found the bugs.
- Someone is applying security patches whether or not you are thinking about it.
- The edge cases you have not imagined yet are already handled, because somebody else hit them first.
- Integrations with the other tools you use already exist.
- If your internal expert leaves, the product still works.
That last one is underrated. Custom software has a bus factor, and for a small business it is usually one.
What this should change: start every conversation with "what would we have to give up to use the standard product", not with "what do we want it to do". The first question produces a decision. The second produces a specification.
The cost people forget
The quote you receive is for building it. The cost of owning it looks like this:
| Cost | Build | Buy |
|---|---|---|
| Initial | Large, one time | Small or none |
| Licence or subscription | None | Ongoing, scales with users |
| Hosting and infrastructure | Yours, forever | Included |
| Security patching | Yours, forever | Theirs |
| Bug fixes | Yours | Theirs |
| New features | You pay for each one | Arrive included |
| Compliance updates when the law changes | Yours | Usually theirs |
| Knowledge if the developer leaves | Your problem | Not a problem |
| Cost of being wrong | Very high | Cancel the subscription |
The honest comparison is total cost over five years including the running line, against the subscription over the same five years. Do it properly and a surprising number of custom builds stop looking clever.
The other asymmetry is the cost of being wrong. A subscription you regret is cancelled at the end of the month. A custom system you regret is a sunk cost, a migration project and an awkward conversation, all at once.
The four cases where building is right
1. It is your actual differentiator.
If the software is the thing customers pay you for, or it is the process that makes you better than competitors, building is correct and buying is impossible. Nobody sells your advantage as a product, because if they did it would not be your advantage.
The test: would your customers notice if this worked exactly like everyone else's? If no, buy it.
2. No product fits, and the workarounds cost more than the build.
Sometimes the standard products genuinely do not fit the workflow, usually in a specialised operation. The discipline here is to cost the workaround honestly rather than describing it as painful. Hours per week, times people, times the rate, times a year. If that number is small, live with it. If it is large and permanent, build.
Beware of the version of this that is really "our process is unusual because nobody has ever questioned it". Half the time the correct fix is to change the process to match the product, and it is free.
3. Glue between systems you already own.
This is the most under-appreciated case and often the highest return. You have a CRM, an accounting package and a website, and a person retypes data between them. A small integration replaces that person's worst hours forever, costs a fraction of a platform build, and carries little risk because each end is a stable product.
If you are choosing the systems to be glued rather than gluing what you have, start with picking your first CRM and CRM management.
4. Licence cost at your scale exceeds build plus run.
Real, but usually later than people think. Per-seat pricing at three hundred users is a different decision from thirty. Run the five-year number, including your running cost, before concluding that the subscription is expensive.
The third option: configure and extend
Most build-versus-buy debates ignore the middle, which is where the answer usually lives.
Take the platform you already pay for and extend it: custom fields and objects, automation rules, a bespoke portal on top of its API, reports that the standard product does not produce. You get the fit of custom software for a fraction of the cost, and the vendor keeps maintaining the hard parts underneath.
The trade is that you are tied to that platform and dependent on its API. For most small and mid-sized businesses that is an acceptable trade, and a far better position than owning a whole system.
Before you commission anything
Six questions. If you cannot answer them, you are not ready to brief anyone, including us.
- What is the measurable outcome? Hours saved, errors avoided, revenue enabled. Not "a system to manage projects".
- What happens if we do nothing for a year? If the answer is "not much", that is useful information.
- Who owns this internally after it ships, and do they know?
- What is the running budget, annually, forever?
- What does it integrate with, and do those integrations exist?
- What is the exit? If the vendor disappears, can someone else pick it up?
Question six is where custom projects go quietly wrong. The protections are ordinary and must be agreed upfront: you own the code and the repository from day one, documentation is a deliverable rather than a favour, the stack is mainstream rather than exotic, and you hold the credentials to your own infrastructure.
If you already built something you regret
Common, and usually recoverable. Three options, in ascending order of cost:
Stabilise and keep. If it works and the only issue is that nobody understands it, the fix is documentation and a second person who knows it. Cheap, and often enough.
Strangle it gradually. Move one function at a time to a standard product, leaving the custom system to shrink. Lower risk than a single migration and it can be paused.
Replace it. Sometimes right, and rarely as urgent as it feels. Do the five-year maths on the replacement before committing, including the migration of data nobody has looked at in years.
What not to do is rebuild the same system in a newer framework because the current one feels dated. That is expensive, produces no business change, and lands you in the same position three years later.
Frequently asked questions
Should a small business build custom software?
Usually not. Buy a standard product, or configure and extend one you already pay for. Build only when the software is your actual differentiator, when no product fits and the workarounds are genuinely costly, when you need integration between systems you own, or when licence costs at your scale clearly exceed building and running it.
How much does custom software cost to maintain?
Plan for a meaningful annual percentage of the original build cost, every year, covering hosting, updates, security patching, small changes and someone who understands it. A build budget with no running budget behind it is an incomplete plan, not a cheap one.
Is it cheaper to build software now that AI can write code?
First-draft code got much cheaper. Reviewing, owning, securing and operating it did not, and those are the larger share of lifetime cost. The build-versus-buy arithmetic moved less than the headlines suggest. We set out the detail in AI coding agents in 2026.
What is the biggest risk with custom software?
Key-person dependency. One developer who understands the system, no documentation, and no second pair of eyes. Fix it by owning the code from day one, requiring documentation as a deliverable, and insisting on a mainstream technology stack.
How do I know if our process is genuinely unusual?
Ask three businesses like yours what they use. If they all use a standard product happily, your process is probably a habit rather than a requirement, and changing it is free.
Where to go next
If you have concluded that building is right, we do it with the ownership, documentation and handover terms described above as standard: custom software development. If you are not sure, that conversation is free and we will tell you when buying is the better answer. Describe the problem rather than the system you had in mind.
