Build vs buy
Custom Software vs SaaS for Small Business
Reviewed by Noah Altit · Updated September 2, 2026
Buy by default. Build when the generic tool cannot reach the shape your business needs, when per-seat pricing scales badly against your growth, or when the value is in connecting systems that no vendor connects for you. The comparison should run over three years and include maintenance on the custom side and workaround labour on the SaaS side, because leaving either out produces the wrong answer.
The honest comparison
Most build-versus-buy arguments compare a build quote against a monthly subscription and stop there. That comparison is wrong in both directions. Here is the full picture.
| Factor | Off-the-shelf SaaS | Custom build |
|---|---|---|
| Upfront cost | Low. Often a free trial and a card. | Substantial. The whole cost lands early. |
| Ongoing cost | Per seat or per usage, and it rises with your growth | Hosting, API usage, and maintenance, which scale with system size rather than headcount |
| Time to value | Days | Weeks to months |
| Fit to your process | Whatever the vendor decided, plus configuration | Exactly your process, which is also a risk if your process is bad |
| Hidden cost people forget | Workaround labour, spreadsheet shadow systems, and paying for seats that barely use it | Maintenance, and the fact that software nobody owns degrades |
| Integration | Whatever the vendor built. If your combination is unusual, no one built it. | Whatever you need, which is usually the actual reason to build |
| Vendor risk | Price rises, feature removal, acquisition, shutdown | Key-person risk if only one person understands it |
| Exit cost | Data export and migration, sometimes painful | You own it, but you also own it forever |
The break-even arithmetic
Do this before you talk to anyone selling either option. It takes ten minutes and it usually settles the question.
For the SaaS side: multiply monthly cost per seat by the number of seats you expect in year three, not today. Multiply by 36. Then add the labour cost of the workarounds, which is the time your team spends re-entering data, maintaining a parallel spreadsheet, or doing manually what the tool cannot do. That last number is the one businesses systematically ignore, and it is often larger than the subscription.
For the custom side: take the build quote, then add roughly 15 to 20 percent of it per year for maintenance, hosting, and small changes. Multiply the annual figure by three and add it to the build.
A worked example with round numbers. Twelve seats at $60 a month in year three is $720 a month, or $25,920 over 36 months. If two people each lose three hours a week to workarounds, that is 312 hours a year, or roughly $10,900 a year at $35 loaded, which is $32,700 over three years. SaaS total: about $58,600. A $20,000 build at 18 percent annual maintenance is $20,000 plus $10,800, or $30,800. In that scenario custom wins clearly.
Change the assumptions and the answer flips. Four seats instead of twelve and no meaningful workaround labour, and SaaS is $8,640 over three years against $30,800. Buy the product. The arithmetic is not ideological; it just depends on your actual numbers.
The number that decides most of these comparisons is workaround labour. If you cannot estimate it, track it for two weeks before deciding.
Five signals you should build
These are the conditions under which we would encourage a build. If none of them apply to you, we would tell you to buy.
- You have evaluated three or more products and each one required a workaround you were uncomfortable with. That is evidence of a genuine shape mismatch, not a search problem.
- Your competitive advantage is the process itself. If how you do the work is why clients choose you, encoding it in generic software flattens it.
- You need two or more existing systems to behave as one, and no integration exists. This is the most common legitimate reason and the hardest to buy your way out of.
- Per-seat costs are growing faster than the value you get per seat, typically because most seats are light users paying full price.
- You are subject to data-handling requirements the vendor cannot satisfy, whether that is residency, retention, access logging, or isolation.
Five signals you should buy
We turn down work on these grounds regularly, and it is a better outcome for everyone than a build that should not have happened.
- The category is solved. CRM, accounting, email marketing, e-signature, payroll, helpdesk. Do not rebuild these.
- Your process is still changing. Automating an unsettled process bakes in a shape you will want to abandon in six months.
- Nobody internally will own the software after launch. Unowned custom software becomes a liability faster than most people expect.
- The main complaint is cost rather than fit. If the product does the job and you just want it cheaper, a build almost never comes out cheaper once maintenance is counted.
- You need it working in two weeks. That is a buying timeline, not a building one.
The hybrid most businesses actually need
Framing this as a binary is where the money gets wasted. In practice the sound architecture for a small business is to buy the commodity layers and build only the connective tissue and the parts unique to you.
Keep the CRM you bought. Keep the accounting software. Keep the e-signature tool. Build the layer that moves data between them according to your rules, and build the client-facing surface that reflects how you actually work. That build is smaller, cheaper, and lower risk than replacing any of the products, and it captures most of the value people are chasing when they talk about custom software.
Questions buyers ask
Is custom software cheaper than SaaS in the long run?
Sometimes, and it depends almost entirely on seat count and workaround labour. Run a three-year comparison that includes maintenance at roughly 15 to 20 percent of build cost annually on the custom side, and workaround labour on the SaaS side. At low seat counts with a good product fit, SaaS usually wins. At higher seat counts with poor fit, custom usually wins.
How much should I budget for maintaining custom software?
A common planning figure is 15 to 20 percent of the original build cost per year, covering hosting, third-party API usage, dependency updates, and small changes. Systems that integrate with more external services sit at the higher end because those services change on their own schedule.
What happens if the developer who built it disappears?
This is the real risk with custom software and it is manageable if you insist on it up front: you own the repository, the documentation is written for someone other than the author, and the stack is mainstream rather than exotic. Ask any studio how handover works before you sign, and be wary of a vague answer.
Can we start with SaaS and move to custom later?
Yes, and it is often the right sequence. Using a product first teaches you what your process actually needs, which makes the eventual build better scoped. Plan for data export early so the migration is not a surprise.
What is the smallest sensible custom build?
Usually a single workflow with one clear outcome and a small number of integrations. Starting narrow gives you a system in production quickly, and the second phase is then informed by real usage rather than assumptions.