Build vs. Buy: A Decision Framework You Can Apply in 30 Minutes

---

title: "Build vs. Buy: A Decision Framework You Can Apply in 30 Minutes" metaTitle: "Build vs Buy — A 30-Minute Decision Framework" metaDescription: "A clear, opinionated build-vs-buy decision framework with worked examples. No vendor pitch — just the questions that actually decide it." excerpt: "An opinionated build-vs-buy framework you can run yourself in 30 minutes. Six questions, real worked examples, and an honest answer at the end." date: "2026-05-04" readTime: "10 min read" category: "Strategy" coverImage: "/images/blog-stub.jpg"

The build-vs-buy question is the most common conversation we have with operators and founders, and it's also the one most often answered badly. The two failure modes are predictable. One: somebody buys software because it was easy and cheap to start, ignores the fit issue, and ends up paying for a stack that doesn't work. Two: somebody builds custom because they had the budget and the ego, ignores how good off-the-shelf actually is for commodity workflows, and ends up with an expensive in-house version of QuickBooks.

You don't need an MBA to avoid both. You need a framework that respects how the question actually breaks down — and you need to be honest about your answers. The version below is the one we walk people through on the Free Teardown. Six questions, in order. You can run it yourself in 30 minutes if you'd rather.

Question 1: how generic is the workflow?

Start here, because nothing else matters until you've answered it.

A workflow is generic if most businesses do it roughly the same way. Accounting is generic. Email marketing is generic. Payment processing is generic. Document signing is generic. Time tracking is mostly generic. The market for these workflows is enormous, the SaaS competition is fierce, and the tools are good. Renting these workflows is almost always the right call.

A workflow is specific if the way you do it is meaningfully different from how a typical business in your industry does it — or if you're in an industry that's small enough that no SaaS company has prioritized it. Field service dispatch with the actual logic your dispatcher uses. Quoting with your specific pricing rules and markups. A multi-stage project flow that's unique to your firm. A customer relationship structure that's not "lead → opp → close." Compliance workflows for a regulated niche. Specialty trades. Multi-entity reporting. A specific way you onboard or compensate a workforce.

The test: if you described your workflow to three other people in your industry, would they nod or would they look at you funny? If they nod, it's generic. Buy. If they look at you funny, it's specific. Now you have a real build-vs-buy question.

Worked example. A 20-person electrical contractor in Vancouver wonders whether to build a custom tool. Accounting? Generic — keep QuickBooks. Email? Generic — keep Google Workspace. Dispatch with their specific multi-crew logic and BC drive-time rules? Specific. Quoting with their price book and AI line-item classification (we've actually built this one)? Specific. The build-vs-buy decision narrows fast: keep the generic stack, build the specific workflows.

Question 2: what does five years of buying actually cost?

Most owners look at SaaS one month at a time. The five-year number is what matters.

Add up the realistic five-year cost of staying on the SaaS path: subscription fees with realistic price increases (5–12% annually), the cost of integrations to make the tools talk to each other, the human cost of the shadow system that exists because the tools don't fit cleanly, and the staff time burned on workarounds. That last one is invisible to most owners. It's also usually a five-figure annual line.

Now compare it against the realistic cost of the build path: a one-time build cost (usually $25K–$80K for a focused first version) plus ongoing maintenance (typically 10–20% of build cost per year, often less for stable tools).

If the SaaS path is meaningfully cheaper across five years, buy. If the numbers are close, lean toward whichever side fits your other answers. If the build path is meaningfully cheaper — which it often is past about $4,000–$5,000/month in SaaS spend — that's a real signal.

We laid out the full math for a 15-person service business in this post. The five-year SaaS number for that example was around $435K. The five-year custom build number was around $113K. Your numbers will differ. Run them.

Question 3: how stable is the workflow?

Custom software is most expensive when the workflow is changing constantly. If you're going to throw out the whole pricing structure next year, build the workflow on something that can be reconfigured easily — usually SaaS plus spreadsheets, until the workflow stabilizes.

Custom software is most valuable when the workflow is stable. If you've been doing it the same way for three years and you'd do it the same way for the next five, the build will pay back many times over.

The test: would the workflow you'd build today still be roughly correct in 18 months? If yes, build is fine. If no, wait — buy something flexible in the meantime, let the workflow harden, then build.

Worked example. A two-year-old early-stage SaaS startup wonders whether to build a custom CRM. Their sales process is changing every quarter as they figure out who their actual customer is. Building a custom CRM at this stage would freeze a process that's still being figured out. Buy HubSpot or whatever, keep iterating, and revisit in 12 months once the process stabilizes.

Question 4: what happens if the SaaS vendor changes the deal?

Every SaaS company eventually does the thing. The annual price hike. The feature you depended on getting moved to a higher tier. The acquisition. The "we're sunsetting that integration" email three months out. The mandatory migration to a new platform that's slower than the old one.

The question is what that does to your business when it happens.

If the cost is "annoying but survivable" — you'd switch to a competitor in a quarter and life would go on — keep renting. The optionality of SaaS is real and worth something.

If the cost is "this would actually break us" — the tool is so deeply embedded in operations, or your data is so locked in, or the cost of switching would be measured in weeks of lost productivity — that's a serious signal toward owning. The day a vendor changes the deal on a workflow your business depends on is the day you wish you owned it.

This is the question most owners never ask, because the SaaS vendor is your friend right up until the day they aren't.

Question 5: do you actually want to own this?

This is the soft question, but it's a real one. Owning custom software isn't free. It's a small ongoing relationship — with whoever built it, or with an in-house engineer, or with an outsourced maintenance partner. There's a 10–20%-of-build-cost-per-year line for keeping the tool healthy. Things change in the underlying frameworks. Browsers update. Integrations break. Bugs appear. None of it is dramatic, but ignoring it for two years is how you end up with a brittle tool nobody can touch.

If you're the kind of operator who'd rather pay a vendor and never think about the tool, that's a legitimate preference. SaaS is built for you. Don't fight it.

If you're the kind of operator who wants to own a real asset on the balance sheet — software you can extend, sell, hand to a new partner, or take in-house if you ever hire your first engineer — custom is built for you. The ongoing relationship is part of the deal, and it's not heavy.

Neither answer is wrong. But the answer should be intentional. We've watched too many builds go badly because the buyer didn't actually want the ownership; they just wanted the cost savings.

Question 6: have you crossed the operational threshold?

Some build-vs-buy decisions are just a question of size. Below a threshold, SaaS is cheaper, easier, and good enough. Above the threshold, custom is cheaper, easier, and substantially better.

Rough thresholds, observed across the businesses we work with in Vancouver and Greater Vancouver:

• Under 8 employees, under $1.5M revenue, under $1,500/month SaaS spend. Almost always: stay on SaaS. The math doesn't work yet, the workflows aren't stable yet, and you have better places to put your money.
• 8–20 employees, $1.5M–$5M revenue, $1,500–$4,000/month SaaS spend. Mixed. The decision depends heavily on questions 1, 3, and 4. Some shops at this size benefit from custom, many don't.
• 20–60 employees, $5M–$25M revenue, $4,000–$10,000/month SaaS spend. Most of the time: custom for the specific workflows, keep SaaS for the generic ones. The math has flipped, the workflows have stabilized, and the shadow system has gotten expensive.
• 60+ employees, $25M+ revenue, $10,000+/month SaaS spend. Almost always: custom for anything specific, with a serious internal owner for the tool.

These aren't rules. They're starting points. But the size of the operation matters more than most build-vs-buy frameworks acknowledge.

A worked example end-to-end

Let's run the framework on a real shape we see often: a 25-person commercial HVAC company doing $8M in revenue in the Lower Mainland, paying about $6,500/month across ServiceTitan, an additional dispatch tool, an e-sign add-on, a time tracker, QuickBooks Online with payroll, Google Workspace, and a couple of single-purpose tools.

• Q1 (generic vs. specific): Their dispatch logic and quoting are highly specific — commercial HVAC, multi-day jobs, complicated phasing. Their accounting is generic. Mixed answer pointing toward "build the specific stuff, keep the generic stuff."
• Q2 (five-year cost): $6,500/month with 7% annual increases compounds to about $450K over five years. A custom build replacing 4–5 of those tools is roughly $60K up-front plus $4,800/year in hosting/maintenance — about $84K over five years. Plus the retained generic SaaS (QuickBooks, Google Workspace, a couple of others) at maybe $1,200/month, or another $80K over five years. Total custom path: $164K over five years. Save: about $286K. Strong build signal.
• Q3 (stability): They've been operating this way for six years. Workflow is stable. Build signal.
• Q4 (vendor risk): ServiceTitan price increases would hit them hard. They've already absorbed two. Build signal.
• Q5 (ownership): The owner has a working relationship with their existing tooling vendors and is open to a similar relationship with a build partner. Neutral signal.
• Q6 (size): 25 employees, $8M revenue, $6.5K/month SaaS spend. Squarely in the "build for specific, keep for generic" zone. Build signal.

Five out of six signals favor a custom build for the specific workflows, keeping the generic SaaS in place. That's the recommendation. And it's typical of the businesses we see at this size — once the framework is run honestly, the answer is usually clear.

What to do with the framework

If you ran this on your own business and the answer was "obviously buy," great — go buy, save the build money, and don't waste another minute on this. If the answer was "obviously build," talk to two or three serious build partners and start. If the answer was unclear or somewhere in the middle, that's the conversation we have on a Free Teardown. 30 minutes, written summary, real recommendation. We'll tell you which side of the line you're on, and what the next step is, even if the answer is "do nothing."

Build vs. buy isn't a hot take. It's a math problem with six inputs. Run the inputs honestly and the output usually makes itself obvious. If you'd like a second pair of eyes, that's what we're here for.