Quick takeaways
- Buy when the process is a commodity. Build when it's your competitive advantage. That single distinction settles most of these decisions.
- Compare five-year total cost of ownership, not subscription price against a development quote. Both sides get underestimated, usually by two to three times.
- Per-seat pricing scales with headcount. Custom software costs are largely fixed after the build. For most business applications, the crossover sits somewhere between 25 and 75 users.
- The clearest signal you already need custom software is workarounds — spreadsheets, scripts, and manual handoffs that exist to compensate for what your tools can't do.
- Leaving a SaaS platform is expensive. Data extraction, re-implementation, retraining, and lost productivity mean switching costs run well into six figures for a mid-sized company.
- Custom doesn't have to mean big-bang. Build the narrowest slice that removes the most painful workaround, ship it in weeks, and expand from evidence.
Somebody on your team has a spreadsheet.
It sits between two systems that don't talk to each other. Every Monday, they export from one, clean the data, paste it into the other, and fix whatever broke. It takes three hours. Nobody planned it. It just appeared, the way these things do, and now the business quietly depends on it.
That spreadsheet is the build-vs-buy decision, already being made. You're paying for custom software in labor. You're just not getting any of the benefits.
This is a framework for deciding when to keep paying that way and when to stop.
The question isn't features. It's fit.
Most build-vs-buy comparisons turn into feature checklists. Does the tool do X? Does it integrate with Y? Those questions are easy to answer and they rarely decide anything, because feature lists converge. Any mature product in a category does roughly what the others do.
The real question is different: how much does your business have to change to fit this tool, and is that change worth what you're saving?
Sometimes it clearly is. If you're adjusting your expense approval flow to match what a well-built expense product expects, you're probably getting a better process than the one you had. Vendors have seen ten thousand companies do this and built for the pattern that works.
Sometimes it clearly isn't. If your fulfillment process is the reason customers choose you over a larger competitor, and the software makes you fulfill the way everyone else does, you've just paid a subscription to become less distinctive.
Buy when the process is a commodity
There's a category of software nobody should be building. Payroll. Email. Accounting. Calendars. Video calls. Password management.
Three things make these commodities:
The process is standardized by law or convention. Payroll works a particular way because tax authorities require it. Your version wouldn't be better, just yours.
Vendors iterate faster than you ever will. A payroll company employs people whose entire job is tracking tax law changes across fifty states. You would be assigning that to someone who has four other responsibilities.
Getting it wrong is expensive and getting it right earns you nothing. No customer has ever chosen a supplier because of their internal expense system.
The test is simple: if a customer would never notice this software existed, and a mature product covers most of what you need, buy it. Adjust your process. Move on.
Build when the process is the product
The opposite case is narrower than most agencies will admit, but it's real.
When the workflow is your competitive advantage. If how you do something is why customers pick you, software that forces you into the standard way erodes the thing you're selling. A specialty logistics company with a routing method competitors can't match shouldn't be running the same routing software competitors buy.
When integration overhead exceeds build cost. Sometimes the tool does 70% of the job, and the remaining 30% requires three more subscriptions, a middleware layer, and someone maintaining the connections. Add those up honestly. The "cheaper" option often isn't.
When licensing scales painfully against growth. Per-seat pricing is fine at twenty people. At two hundred, it's a fixed cost that grows every time you hire.
When the workarounds have become a job. Back to that spreadsheet. If your team maintains manual processes to compensate for tooling gaps, you're already paying for custom software — you just aren't getting it. One useful exercise: for two weeks, ask everyone to note each time they say "the system can't do that, so I..." Add up the hours. That number is your current cost of not building.
The comparison that actually matters
Here's where most build-vs-buy analysis goes wrong. It compares a monthly subscription against a development quote. Those aren't comparable numbers — one is a recurring operating cost, the other a one-time capital cost with a maintenance tail.
Compare five-year total cost of ownership. Both sides tend to get underestimated by a factor of two to three, and they get underestimated in different places.
Off-the-shelf
Custom software
Year one
Subscription + implementation + training + integration
Full build cost
Ongoing
Renewals, price increases, per-seat growth, add-on modules
Hosting plus maintenance, roughly 10–20% of build cost annually
Scales with
Headcount
Complexity, not headcount
Hidden costs
Consumption charges, module upsells, mandatory tier upgrades
Requirements drift, integration surprises
At the end
You have a lapsed subscription
You have an asset you own
Switching later
Data extraction, re-implementation, retraining
You control the roadmap
What buyers forget on each side
Buying hides its cost in implementation, annual increases, and consumption pricing. Industry analysis consistently puts real SaaS total cost at well above the advertised subscription once integration, training, and seat growth are added.
Building hides its cost in maintenance and the requirements you hadn't thought of yet. Budget 10–20% of build cost per year for hosting, monitoring, security patching, and small feature work. Software isn't a purchase; it's closer to a vehicle.
The crossover point
Per-seat pricing scales with your team. Custom software costs are largely fixed after the build. That means there's a headcount where the lines cross, and for most business applications it lands somewhere between 25 and 75 users.
Below that, off-the-shelf usually stays cheaper. Above it, the math moves and keeps moving — every hire makes the subscription more expensive and leaves the custom option unchanged.
Worth running for yourself: take your current SaaS spend, project it forward three years at your expected headcount, and put it next to a build estimate. If the comparison makes you uncomfortable, that discomfort is the answer.
The cost nobody puts a number on
Every build-vs-buy article mentions vendor lock-in. Almost none of them price it.
Leaving a SaaS platform after three or more years means data extraction and cleanup, re-implementation on the new system, retraining everyone who used the old one, and a stretch of reduced output while the team adjusts. For a mid-sized company, that lands in six figures.
That's not a reason to never buy software. It's a reason to know what you're signing up for, and to weight it properly against building something where you hold the exit.
The third option most comparisons skip
Build versus buy isn't binary, and treating it that way produces worse decisions than either option.
Buy and extend is the right answer more often than either extreme. Buy the platform for the commodity parts. Build custom layers where your process differs. Connect them properly.
A retailer buys their accounting package and builds a custom inventory allocation system that feeds it. A clinic buys their EHR and builds the scheduling layer their specific patient flow requires. Neither is a full custom build, and neither is a compromise.
This works when the bought platform has a real API, when the boundary between commodity and differentiated is clear, and when someone owns the integration long-term. It fails when the vendor's API is an afterthought — worth checking before you commit, not after.
A decision framework
Work through these honestly. Score them for your situation rather than to justify what you've already decided.
1. Would a customer ever notice this software? No → strong signal to buy.
2. Does a mature product cover 80% of what you need? Yes → buy it and live with the gap. Custom becomes worth it when the missing 20% is the part your business is built on.
3. How many hours a week does your team spend on workarounds? More than ten across the team → you're already paying for custom software.
4. What does the five-year cost look like at your projected headcount? Not today's headcount. The one in your plan.
5. How many systems would this need to talk to? High integration density pushes toward custom, because integration work happens either way — the question is whether you own the result.
6. Does regulation shape how this has to work? Heavy compliance requirements often rule out generic products, or require so much configuration that you've built something anyway, without owning it.
7. Could you actually maintain what you built? The honest version of this question. If the answer is no and you're not planning to fix that, buy.
One dominant factor can outweigh the rest. If the software is your product, that settles it regardless of how the other six score.
De-risking the build
The strongest argument against building is risk, and it's a fair one. Large software projects have a poor success record, and the pattern is consistent: the bigger the scope, the worse the odds.
Which points at the answer. Don't build the whole thing.
Start with the narrowest slice that removes the most painful workaround. Ship it in weeks. Put it in front of the people doing the work. Expand from what you learn.
This does three things at once. It gets value into the business before the full scope is finished. It surfaces the requirements you hadn't thought of while they're still cheap to handle. And it gives you a real exit — if the first slice doesn't deliver, you've spent a fraction of the budget finding out.
That's how we approach every custom engagement at Softonoma: a first version in eight to twelve weeks, then expansion based on evidence rather than the original plan.
A few things make the difference between a build that works and one that becomes a cautionary tale:
- Spend properly on discovery. Unclear requirements sink more projects than any technical problem. It's the phase buyers most want to compress and the one where compression costs most.
- Insist on working demos every sprint. Not status reports. Software you can open and click. It's the only progress update that can't be wrong.
- Own everything from day one. Source code, infrastructure definitions, and design files in your repositories and your cloud accounts. If handover is conditional on a final payment of an undefined amount, that's leverage being built in deliberately.
- Plan for maintenance before you start. Who owns this in year three?
Frequently asked questions
Is custom software cheaper than off-the-shelf?
Over five years, often yes — but it depends almost entirely on headcount growth. Per-seat licensing scales with your team while custom software costs are largely fixed after the build. Below roughly 25 users, off-the-shelf usually stays cheaper. Above 75, the math has typically flipped. In between, it comes down to how many tools you're replacing and how much integration work you're already doing.
What's the biggest risk of building custom software?
Unclear requirements, not technology. Projects fail because the specification described the process on paper rather than the process as people actually perform it. The second biggest risk is scope — large builds succeed far less often than small ones, which is why starting narrow is the single most effective risk reduction available.
How do I know if our workarounds justify a custom build?
Measure them. For two weeks, have the team note every instance of "the system can't do that, so I..." and record the time. If it exceeds ten hours a week across the team, you're funding a custom build through labor already. At that point the question isn't whether to spend the money — it's whether to keep spending it invisibly.
Can we build custom software without a technical team?
Yes, though you need one person internally who can make decisions and answer questions quickly. The most common cause of delay on agency-built projects isn't engineering speed — it's a decision sitting unmade for three weeks. You don't need an engineer. You need someone who understands the process deeply and has authority to settle questions about it.
Where this leaves you
Build versus buy isn't a question about software. It's a question about which parts of your business are genuinely yours and which parts are the same as everyone else's.
Buy the commodity. Build the difference. Extend where the line runs through the middle.
And before either, measure the workarounds. Most companies discover they've already committed to custom software — they're just paying for it in three-hour Monday mornings instead of in code.
If you're weighing a build and want a straight technical read on scope, cost, and whether it's worth doing at all, our custom software development team offers a free consultation. Sometimes the answer is that an off-the-shelf tool will do fine, and we'll tell you that.