There are a lot of build-vs-buy frameworks. We have read the ones that rank for this question, and almost all of them are asking you a version of this: is this software core to your differentiation, and is it the best use of your engineering capacity?
That is a good question. It is also a question for a company that has engineering capacity.
If you run a nine-person HVAC business, "build" does not mean pulling two developers off the roadmap. It means hiring a stranger, spending money you would notice, and then owning software forever with nobody in the building who can change it. That is a completely different decision, and it deserves a framework that does not quietly assume a CTO.
One more thing worth saying up front: we sell custom software. A framework whose every branch concludes "hire us" is not a framework, it is an advertisement, and the internet has enough of those. Two of the four branches below end in don't build anything. We mean them.
The framework you've read assumes you have engineers. You don't.
Here is what changes when the engineering team is zero:
"Opportunity cost" stops being the main variable. For a company with developers, building means not building something else. For you, building means spending cash and acquiring an obligation. Those are different risks and they resolve differently.
"Maintenance" stops being a line item and becomes a structural problem. A company with engineers absorbs maintenance into existing capacity. You cannot absorb it into anything. Someone external has to do it, forever, or it does not get done — and unmaintained software is not stable software, it is software accumulating an expensive migration. We have written the full list of what that actually involves: who maintains custom software after it's built.
"Core to differentiation" is the wrong test. It is a strategy-deck question. The question that actually predicts whether a small business should build is much blunter: how many hours a week does the current mess cost, and how long has it been getting worse?
Your per-seat costs bite earlier and harder. A 40-person company absorbs a price increase. A nine-person company notices immediately, and a per-seat tool with three features you need and eleven you do not is a permanent, growing tax on being slightly unusual.
When buying is the right answer
Buy, and stop reading, if any of these are true.
An off-the-shelf tool covers 80% or more of what you do. This is the single most reliable rule in the whole decision, and it is the one the other frameworks get right. Eighty percent plus a small annoyance beats a hundred percent that you now own. Adapt your process to the tool; it is cheaper than the alternative and you will be live on Thursday.
The process is not actually settled. If how you do the work has changed twice this year, building now means building the wrong thing precisely. Buy something flexible, let the process stabilise, revisit in a year.
The pain is a person problem wearing a software costume. Some of what feels like a tooling problem is an unclear handoff between two people, or a step nobody owns. Software will encode the confusion and make it permanent. Fix the process on paper first — if the paper version works, you may not need to build at all.
It is not close to the money. If the broken thing does not touch revenue, delivery, or a compliance obligation, buy the adequate thing and spend the attention elsewhere.
When the spreadsheet is actually fine
Nobody writes this section, so here it is.
A spreadsheet is a legitimate piece of software. It is fast, flexible, universally understood, and free. A great many excellent businesses run on spreadsheets for years and are right to.
Keep the spreadsheet when: one person maintains it, that person is not a bottleneck, it is backed up, the volume is not growing quickly, and nothing critical depends on someone remembering an unwritten step.
Replace it when at least three of these are true:
- More than two people edit it, and versions have diverged at least once
- The same data is typed into it and into another system
- Somebody spends a recurring, predictable block of time every week just moving data between places
- A mistake in it has already cost you real money or a customer
- Only one person understands how it works, and you feel a flicker of something when they book a holiday
- You have started building automations around it to compensate for it
Three or more and the spreadsheet stopped being a tool and became a liability. That is the honest trigger point — not a revenue milestone, not a headcount number.
The real cost of "build" when nobody in the building writes software
If you do build, price the whole thing, not the launch. The build quote is roughly half to two-thirds of the five-year number, and the missing part arrives as a series of unplanned events rather than as a budget line. The arithmetic, with the industry's own published maintenance benchmarks, is here: what custom software actually costs a small business.
The part that does not appear on any quote is your time. Custom software needs somebody on your side to explain the work, answer questions, test what comes back, and decide things. For a small business that person is you or your best operator, and they have a day job. Underestimating this is the most common reason small-business software projects go badly, and it is not the developer's fault.
And then the structural question, which you should answer before you sign anything: eighteen months from now, who applies the security patch? If you cannot name a person, you have not yet made a decision — you have deferred one.
The third option most frameworks skip
Build vs buy is presented as binary. There is a third shape and it is the one most under-twenty-person businesses actually want:
Have it built for you, and have it run for you. Someone builds the software fitted to how you work, then hosts it, patches it, upgrades it and answers the phone — for a monthly price, ongoing. You get the fit of building without acquiring the obligation of owning.
This is what Truss does, so weigh the recommendation accordingly. What is not a sales point is the observation underneath it: handover to a business with no engineers is not a transfer of ownership, it is a transfer of risk. Whatever you decide and whoever you hire, that is the sentence to keep.
Two honest caveats. It usually costs more per month than a one-off build costs per month amortised — you are paying for the running, because the running is real work someone has to do. And you are entering an ongoing relationship, which raises fair questions about lock-in, ownership and exit. Those questions have answers, and any vendor who gets vague about them has answered you. The full version of how the model works, including what happens if you stop paying: custom software on a monthly price.
A decision checklist for a business with no engineers
Work down. Stop at the first yes.
- Does an off-the-shelf tool cover 80%+ of the process? → Buy it. You are done.
- Is the process still changing month to month? → Wait. Buy something flexible, revisit in a year.
- Does the mess cost less than a few hours a week, and is it not near the money? → Keep the spreadsheet. Spend the attention on something that pays.
- Is the process settled, specific to how you work, costing real hours every week, and close to revenue or delivery? → Build is justified. Now answer one more question before you choose a vendor: who runs it in year two? If you cannot name a person, you do not want a one-off build — you want it built and run.
Most small businesses that get this wrong do not get it wrong at step 4. They get it wrong by never asking the year-two question at all.