Build vs. Buy: The Decision Framework We Use Before Building an Internal Tool
Build-vs-buy shouldn't be a gut call. Here's the five-question framework we use to decide when a focused internal tool beats yet another SaaS subscription.
A team lead pings you: “Can we just build this ourselves instead of paying for another tool?” Two engineers say yes immediately. One says it’ll be a maintenance nightmare. Nobody has actually written down what would make either answer correct — so the loudest person wins, and six months later you either have an orphaned internal app nobody maintains or a SaaS contract you’re working around instead of with.
We make this call constantly — for our own operations and for clients evaluating whether to build. The mistake almost everyone makes is treating it as a coding question (“can we build this?”) when it’s really an ownership question (“do we want to own this for the next five years?”). The answer to the first is almost always yes. The answer to the second is usually no — and the whole point of a framework is to find the cases where it’s an honest yes. Here’s the one we use.
Why “we can build that” is the wrong starting point
The reason build-vs-buy goes wrong is that the cost of building is front-loaded and visible, while the cost of owning is spread out and invisible. The version-one demo takes a weekend and feels like a win. The actual bill arrives over years: auth, backups, access control, the edge cases you didn’t know existed, the security patch nobody scheduled, the rewrite when the one engineer who understood it leaves.
Buying has the opposite shape. The cost is obvious — a recurring invoice you can see — and the constraints are hidden until you hit them. The average company ran 106 SaaS apps in 2024, down from 112 the year before (BetterCloud, 2026 SaaS statistics), and the reason the number is finally falling isn’t that buying stopped working. It’s that a lot of those subscriptions turned out to cover 10% of what a team needed while forcing workarounds for the other 90%. Gartner projects that by 2027, 25% of SaaS spending will be overspend from unused entitlements and overlapping tools (via BetterCloud). You are not just buying software. You are buying that software’s model of how your work should go.
So the real question isn’t “build or buy.” It’s “which kind of cost do we want, for this specific workflow?” Five questions get us to the answer.
1. Is this workflow core to how we make money, or is it plumbing?
This is the first fork and it settles most cases on its own. If the workflow is a genuine competitive differentiator — the thing you do better than competitors, the reason customers pick you — owning it is worth the long-term cost, because no vendor will build your edge for you.
If it’s plumbing — payroll, expense reports, email, calendars, generic CRM for a generic sales motion — buy it. Building commodity infrastructure to save a subscription fee is how teams end up maintaining a worse version of something a vendor maintains full-time for thousands of customers. Be ruthless here. Most workflows are plumbing, and that’s fine.
2. How well does the off-the-shelf model actually fit?
When something is worth examining, look at fit before cost. Generic tools encode a generic model — a CRM assumes contacts, deals, pipelines, activities. If your workflow matches that model, a CRM is the right answer and you should use one. We’ve said exactly that to clients who expected us to pitch a build.
The build case appears when the fit is genuinely bad: an import-review-act loop where the same record should never need re-evaluation, a qualification process with rules no pipeline stage can express, a workflow stitched across tools that don’t talk to each other. We dug into this in When a CRM Is Too Much — the tell is when your team spends more energy fighting the tool’s assumptions than doing the work. A 70% fit you can live with beats a build. A 30% fit you’re constantly working around is a real signal.
3. What’s the total cost of ownership over three years — not the build cost?
Compare the honest three-year number on both sides, not the sticker price.
On the buy side that’s not just the subscription — it’s per-seat pricing as you grow, the annual price increases that have become routine, the integration glue, and the migration cost when you eventually outgrow it. On the build side it’s the initial build plus hosting, plus the maintenance tail: security updates, dependency upgrades, the support load when it breaks, and the bus-factor risk if only one person understands it.
That maintenance tail is the line item teams forget. A rule of thumb that’s served us well: estimate the build, then assume ongoing maintenance runs a meaningful fraction of that every year, indefinitely. If a tool is $30/user/month and you have 6 people who’ll use it for three years, that’s $6,480 — and for a narrowly scoped workflow, a focused internal tool can sometimes come in under that and fit perfectly. As seat counts climb, per-user pricing matters less than support, reliability, and operational complexity, and the math often flips toward buying — but there’s no magic seat count, and the economics turn on seat price, workflow uniqueness, and integration cost as much as headcount. Run your actual numbers; don’t reason from the demo.
4. Can we scope it small enough to actually finish and maintain?
The internal tools that succeed usually start aggressively narrow. They solve one workflow precisely and resist expanding until they’ve earned it. The ones that fail try to become the platform on day one — they grow a settings page, then a permissions system, then a plugin model, and now you’ve built the SaaS you were trying to avoid, except worse and unfunded.
This is the discipline that makes building viable at all. When we built our own internal accounting tool instead of buying SaaS, it worked precisely because it refused scope: one job, local-first, no account system, no roadmap. If you can’t draw a hard boundary around the problem — if every stakeholder has a “while you’re in there” — that’s a sign the real requirement is broad, and broad requirements are what SaaS vendors amortize across thousands of customers. Buy.
Narrow-to-start isn’t the same as frozen-forever, though. The best internal tools tend to become platforms by accident, one solved problem at a time — not by being designed as one up front. Our own project tracker started as a bare replacement for spreadsheet time-tracking; only after that earned its keep did it grow project tracking, then scrum, support and incident workflows, a small CRM, and eventually AI agents — none of it on a day-one roadmap. The rule isn’t “build a platform,” it’s “solve one workflow well, then earn the right to expand.”
5. Do we have a credible owner for the next five years?
Software you build is software you own forever. The question isn’t whether your team can build it — it’s whether there’s a named, lasting owner who’ll patch it, answer questions about it, and care when it breaks. “We’ll all sort of look after it” means nobody will.
This is where honest teams say no even when questions 1–4 said yes. An internal tool with no owner is a liability with a login page. If you can’t point at the person or team accountable for it in year three, buy the thing and let the vendor carry that weight.
What tips the scale toward build
When the answers line up — it’s differentiating, the off-the-shelf fit is bad, the three-year math favors building, the scope is narrow, and there’s a real owner — building wins, and modern tooling has lowered that bar. The build that used to need a backend team is now often a focused app on a small stack. We lean on our own Kyte Framework and Kyte Shipyard to go from data model to a working, deployable API fast, precisely so that “build” doesn’t have to mean “stand up a team.” The cheaper building gets, the more often question 1 — is this actually ours to own? — becomes the one that decides it.
It’s also rarely all-or-nothing, and building no longer means recreating everything. Increasingly it means composing — buy the database, the auth provider (Cognito, Auth0, Clerk), the email sending (SES, Postmark), the object storage, and write only the workflow logic that’s genuinely yours. The best setups buy the commodity layer and build the thin, differentiating slice on top. We took that hybrid path when we moved our own site off a hosted CMS onto a static stack on AWS: keep the managed pieces that are pure plumbing, own the part that’s actually our product.
The short version
Build-vs-buy isn’t a referendum on your team’s skills — assume you can build almost anything. It’s a question of what’s worth owning. Run the five: Is it core or plumbing? Does the off-the-shelf model fit? What’s the honest three-year cost? Can we scope it to finish? Is there a five-year owner? If the workflow is differentiating, the fit is bad, the math favors building, the scope is tight, and someone will own it — build, and build it narrow. Otherwise, buy it and spend your engineering on the thing that’s actually yours.
If you’re weighing a build-vs-buy call and want a second opinion from people who do this for a living — including an honest “just buy the SaaS” when that’s the right answer — talk to us about it.
Sources / last verified 2026-06-12: SaaS app-count and overspend figures — BetterCloud, “The big list of 2026 SaaS statistics” (106 apps/company in 2024, down from 112 in 2023; Gartner projection that 25% of SaaS spend will be overspend from unused/overlapping tools by 2027).