Should a small business build custom software or buy SaaS?

Buy SaaS for commodity functions where your process matches everyone else’s: accounting, email, payroll. Consider building where the workflow is your operating edge, exceptions dominate, or you are paying for five tools plus spreadsheets to glue them together. The build option got dramatically cheaper; the default deserves rechecking.

Why is building internal tools cheaper now?

AI-assisted engineering compressed build times from quarters to weeks for workflow-shaped internal software, and modern managed infrastructure removed most of the operational burden. The economics that made SaaS the automatic answer were set before both changes.

What is the risk of customizing SaaS instead of building?

The middle trap: years of configuration, plugins, and consultants spent bending a generic product toward your workflow. You carry subscription costs and switching costs while still not getting the workflow you needed, and everything you invested belongs to the platform.

Who owns custom-built internal tools?

You should, completely: code in your repositories, infrastructure in your cloud, documentation and evals included. If a build proposal keeps hosting or code with the vendor, you are buying SaaS with extra steps.

Custom internal tools vs SaaS: the build-or-buy math changed

The short answer

Buy SaaS where your process is commodity. Build where the workflow is your edge, exceptions dominate, or tool sprawl plus spreadsheets is the real system. The decision changed because the costs changed: AI-assisted engineering compressed custom internal tools from quarters to weeks, while SaaS kept its subscription, its switching costs, and its indifference to your workflow.

For a decade, "never build what you can buy" was simply correct. Building meant quarters of engineering and an ops burden afterwards; renting meant this afternoon. Most of the advice you will read still assumes those prices. They are no longer the prices.

The old math

SaaS won by default because the denominators were brutal. A modest internal tool meant months of senior engineering, then hosting, security patching, and a bus-factor problem forever. Against that, a credible product for a few hundred a month was not a decision at all. The rational strategy was to buy for every function and accept the residue: your workflow adapted to the tool, the gaps filled with spreadsheets, and the subscription stack grew a line at a time.

What changed

Two curves moved. Engineering throughput jumped: with AI-assisted development in senior hands, workflow-shaped internal software now ships in weeks, a claim we make from direct practice, with the caveats spelled out. And the operational burden collapsed: managed infrastructure took the patching, scaling, and backups that used to justify a standing team. What did not change is the SaaS side of the ledger: per-seat pricing, switching costs, and a roadmap that optimizes for the average customer, who is not you.

The advice was priced in 2018. The build side of the ledger was repriced in 2025.

When SaaS still wins, clearly

–Commodity functions. Accounting, payroll, email, documents: your process is everyone's process, and compliance rides along. Buying is correct and boring.
–Deep regulated cores. Systems whose value is years of accumulated edge cases and certifications you should not rebuild.
–Trying a category on. Renting is the cheapest way to learn what you actually need before committing to anything.

When custom wins

–The workflow is the edge. The process that makes you better than competitors should not run on the same tool your competitors rent.
–Exceptions dominate. When half the queue is "special cases," the generic tool is the wrong shape, and the spreadsheet next to it is the confession.
–The glue became the system. Five subscriptions, a spreadsheet that everyone fears, and a person who "knows how it all fits": that is a custom system already, just an unowned, fragile one.
–AI belongs inside it. The step-change use cases, agents that process the queue and judgment encoded next to the data, arrive naturally in owned software and awkwardly through a vendor's roadmap. MIT's 2025 research found purchased AI tools stalling precisely because they never entered the workflow they were bought to change.

The middle trap

The expensive answer is usually neither building nor buying but the years spent customizing a rented product toward a workflow it will never quite fit: configuration consultants, plugins, workarounds, and training for a tool people still route around. You pay subscription plus integration plus switching costs, and everything you invested belongs to the platform. If the customization budget starts rivaling a build budget, the question has answered itself.

The decision, compressed

Signal in your operation	Points to
Process identical to every peer, compliance-adjacent	Buy SaaS
Workflow is a competitive edge or full of exceptions	Build
Spreadsheets glue your tools together and one person holds it	Build, starting from the spreadsheet
You want AI acting inside the workflow, not beside it	Build, with evals and guardrails from day one
You are still discovering what the function even needs	Buy cheap, learn, decide later
A vendor offers custom build but keeps code or hosting	Neither: that is SaaS with extra steps

Two disciplines make the build answer safe where it applies. Scope it fixed and small: weeks, one workflow, production as the deliverable. And contract the ownership handover before anything is built, so what you end up with is an asset, not a dependency with your logo on it. If you are unsure which side of the table your workflow lands on, that is a measurable question: a Workflow Audit answers it with numbers in thirty minutes.