when to build custom software is not a religion. It is a three-year bill. SaaS wins when the job is a commodity. Custom software development wins when the last twenty percent of the job is how you make money, or how you keep people calm on a Tuesday. Most companies do both. The expensive mistake is treating the subscription as cheap because the invoice looks smaller than a build quote.
This guide is for operators, founders, and IT leads who renewed a stack and still live in a spreadsheet named FINAL_v7. You will get a definition of workaround labor, a three-year TCO table you can paste into a budget thread, a five-step test, and the line we use on live products: if the helper is not in the job, people skip it.
Contents
- Key takeaways
- What build vs buy software actually means
- The 3-year TCO test
- Why sticker price lies
- Five steps: buy, hybrid, or build
- When custom software vs SaaS flips
- FAQ
- Conclusion
Key takeaways
- Buy SaaS for work every company does the same way: email, payroll, chat, accounting.
- Build vs buy software is a per-capability decision, not a company-wide slogan.
- Count workaround labor: spreadsheets, paste, shadow inboxes. That is the real SaaS TCO.
- Hybrid is normal: commodity SaaS plus a custom layer on the differentiator.
- Custom software people skip is just more shelfware. Retrofit into the screen people already click.
What build vs buy software actually means
Build vs buy software means choosing, for one workflow, whether you rent a product or own a system shaped around your job.
Buy when the process is a commodity. Drift and Forge's 2026 framing is the useful default: almost nobody should build video conferencing or payroll. Ortem's 2026 note adds the 80 percent test: if the SaaS fits the workflow 80 percent or more and switching costs are low, buy.
Build when the remaining 20 percent is the business. A dispatch rule. A medical-transport phone flow. An HR record people already trust. That 20 percent is where when to build custom software stops being a slide.
Custom software vs SaaS is not "modern vs old." It is "same as everyone else" versus "this is how we win."
The 3-year TCO test
Do not compare year-one subscription to year-one build. Compare three years.
| Cost bucket | SaaS | Custom / hybrid |
|---|---|---|
| License / seats | Grows with headcount | Build plus hosting, usually flatter |
| Integration glue | Zapier, exports, unpaid paste | You own the join, or you retrofit |
| Workaround labor | Spreadsheets filling the 20 percent | Should fall if the job is in the product |
| Change the vendor | Switching cost after training | You own the code; you still pay maintainers |
| Change the process | You wait on their roadmap | You change the workflow |
Worked example (illustration, not a customer quote): 40 seats, four integrations, a nightly spreadsheet to make the tools talk. Year one SaaS looks cheap. Year three the sheet is a second product. That is workaround labor. NextPage-style 2026 TCO writing names the same trap: subscription sprawl plus shadow sheets.
Ask out loud:
- Is this workflow how we beat competitors, or how we file expenses?
- What do people open when it is urgent?
- If we cancelled the tool in 90 days, would Tuesday change?
If the answers are "commodity," "the SaaS," and "yes, Tuesday breaks," you buy. If the answers are "this is the moat," "the spreadsheet," and "Tuesday would not notice," you are not buying a product. You are renting a logo.
Why sticker price lies
Teams hear SaaS TCO and hunt a cheaper plan. Training helps a willing person. It does not fix a tool that adds clicks when a queue is ringing.
The other myth is "we will configure it." Configuration that takes a year is a build you do not own.
The third myth is consolidation: one more platform to unify everything. Sometimes that is right. Often it is a fifteenth login. Consolidation only works if the new screen is where the work already lives. For reclaiming seats before you rewrite, see how to reduce unused SaaS licenses.
Five steps: buy, hybrid, or build
1. Name the job, not the category
"HR system" is a category. "Leave question while a person is waiting" is a job.
2. Score commodity vs differentiator
If three vendors do it the same way, buy. If your operating model is the odd one, do not twist the business to fit the SaaS.
3. Count the sheet
If FINAL_v7 is the system of record, you are already paying for custom software in people-hours.
4. Try hybrid before a rewrite
Keep payroll. Keep email. Put a custom or retrofit layer on the differentiator. We retrofit into systems that already run the business when a rewrite would throw away permissions and integrations. See our comparison of AI retrofit vs a full rewrite and the guide to adding AI without a rewrite.
5. Build only inside the job, then measure last-login
This is the Solvefy line. We build custom software development, SaaS products, and MVPs. If usage does not move after the helper is in the job, stop. You built shelfware.
When custom software vs SaaS flips
Reclaiming seats is cheaper than a build when the tool is a genuine fit. A build (or a retrofit) is cheaper when people have already rejected the official screen.
On AICO, medical transport staff still had to sound calm on the phone. Voice and chat help sat on the booking work they were already doing. Public numbers we can stand behind: about 75 percent less call-handling load, about 98 percent scheduling accuracy. The schedule engine stayed.
On IbisHR, letters, leave, and policy answers sat on records HR already trusted. Admin work dropped about 60 percent. Self-service hit about 95 percent in 90 days.
That is the test for when to build custom software: will seven people still be the only ones in the room after month three, or does the screen earn the Tuesday?
We will not invent a customer who cut TCO 40 percent overnight. Ortem's 50-plus seats and $100k/year figures are market heuristics, not a promise about your stack.
Frequently Asked Questions
When should we buy SaaS without debate?
When the workflow is common, three vendors already compete, and your people already live in that screen.
When to build custom software for a small team?
When the 20 percent is the product you sell, or compliance will not fit shared tenancy. Early-stage teams should still buy commodity tools first.
Is hybrid just "buy and then customize until it is custom"?
No. Hybrid means commodity SaaS untouched, plus a layer you own on the differentiator. Endless configuration of a bad-fit SaaS is the expensive middle.
Can we start on SaaS and build later?
Yes. Validate the job. Then encode the moat. Do not encode the moat into a vendor you cannot leave.
Does custom software always cost more?
Not over three to five years if workaround labor is high. Year one usually costs more. That is the point of the table.
Conclusion
When to build custom software is a three-year test, not a slogan. Buy the commodity. Count the sheet. Put help inside the job people already do. That is the bar we used on AICO and IbisHR, and it is the one we still use.
If you are heading into a renewal, bring the TCO table and the urgent-screen answer, not a feature comparison. The comparison does not matter if Tuesday still lives in FINAL_v7.
Sources: Ortem, Custom software vs SaaS 2026 accessed 2026-09-07; Drift and Forge, Build vs buy SaaS accessed 2026-09-07; NextPage, Build vs buy software 2026 accessed 2026-09-07.
Heading into a renewal with the wrong tool?
Bring the three-year TCO table, not a feature comparison. We help teams buy the commodity, then put custom help inside the job people already do.