Build vs Buy Decision Framework: Stage It by Volume

Build vs Buy Is the Wrong Question (Here's the Right One)

Every founder I work with treats build-vs-buy as a one-time fork in the road. They stand at it for weeks. They build spreadsheets. They poll their advisors. They agonize.

And almost every time, they're asking the wrong question.

The build vs buy decision framework that actually works isn't a binary. The right question is not whether to build or buy, but at what volume the one-time build pays back. That's it. Once you frame it as a volume threshold instead of a permanent identity choice, the agonizing stops and the math takes over.

This is a decision I make on nearly every client engagement. It comes up in the first week, before anyone writes code. It's the same call I walk CEOs through in the build vs buy framework I walk CEOs through, and the answer is almost always "stage it" rather than "pick one and commit forever."

To make this concrete instead of theoretical, I modeled a real example. It's a longevity and telehealth stack, anonymized, where a founder was deciding whether to rent a bundled clinical platform or build their own vertical stack. The recurring numbers screamed "build." The payback math said "not yet."

That gap, between what the monthly cost suggests and what the capital actually demands, is where founders lose hundreds of thousands of dollars. They build too early chasing savings that take seven years to materialize, or they rent forever and overpay long past the point where owning would have won.

The fix is staged build vs buy tied to a volume forecast. Let me show you exactly where the line sits, using real numbers from the model.

Why Recurring Cost Lies to You

Recurring savings vs one-time build cost cliff

Owning is cheaper to run almost everywhere

Here's the trap that catches almost everyone. You line up the monthly SaaS cost against the monthly cost of running a system you own, and owning wins.

In the telehealth stack I modeled, building a vertical clinical stack saves roughly $1,700 a month in recurring cost versus renting a bundled platform. That's real. Once it's running, owning four tools as one system is genuinely cheaper to operate. I've lived this in my own business, where I replaced four SaaS tools with one system I own and the recurring savings are exactly what the model predicts.

So the founder sees $1,700 a month, multiplies it out to $20,400 a year, and starts drafting the build spec. The recurring number seduces them into building too early.

But the one-time build is the real bill

The recurring savings are not the whole bill. They're the easy part.

The one-time build cost for that vertical clinical stack runs $60,000 to $220,000 depending on scope. That's the number the monthly comparison conveniently hides.

And here's the thing about that capital: the recurring savings don't matter until they've repaid it. Saving $1,700 a month is meaningless if you spent $150,000 to unlock it and you fold before you break even.

Monthly comparisons hide the cliff. They make owning look obviously cheaper because they ignore the wall of capital you have to climb first.

Owning four tools as one system genuinely pays off. I'm not arguing against it. I'm arguing it pays off past the crossover, and most founders build long before they reach it.

Payback Period Analysis: When the Math Actually Flips

Run the payback, not the monthly delta

Stop comparing monthly costs. Run the payback period.

The formula is simple enough to do on a napkin:

Payback months = one-time build cost / monthly recurring savings

That single calculation does more to clarify a build-vs-buy call than any feature comparison ever will. It tells you how long you're underwater before the build starts actually saving you money.

The crossover is computable

Let's run it on the telehealth stack at founding-cohort volume.

Payback period formula and crossover by volume

One-time build: $60,000 to $220,000. Monthly recurring savings: $1,700.

That's a payback of 36 to 84 months. Three to seven years before you break even on a system whose only justification was saving money.

At founding-cohort volume, renting wins clearly. It's not close. No early-stage company should sink $150,000 into a build that takes five years to repay when they don't even know if the business survives year two.

But the crossover scales with order volume, and this is the part founders miss. As order volume climbs, the recurring savings climb with it, because owned systems get cheaper per unit while bundled platforms keep charging per transaction.

In the model, a lean own-build clearly wins above roughly 1,000 to 1,500 orders a month. At that volume, the cheap-to-build pieces pay back fast enough to justify the capital.

The full vertical build is different. That one only justifies itself at around 2,500-plus orders a month. The expensive pieces need real scale before their payback window closes inside a reasonable horizon.

So payback period analysis for build vs buy comes down to two questions. First, what's the payback in months at your current volume? Second, and more important: will you hit the volume that shortens that payback before the window closes?

If your payback is 60 months and you won't reach crossover volume for three years, you're not building a system. You're funding a science project. Rent until the forecast says otherwise.

The Four Volume Scenarios I Modeled

I ran the telehealth stack across four volume scenarios, because the right answer changes at each one. That's the whole point: a one-time fork can't be right when the correct decision flips four times as you grow.

Four volume scenarios with different right answers

Founding cohort

Low order volume. The payback on any serious build is 3 to 7 years.

Rent the bundled platform. Build nothing expensive. Don't sink capital into infrastructure you can't repay before you've even proven the business. The recurring savings are real and completely irrelevant at this stage.

Early traction

Around 1,000 to 1,500 orders a month. This is where the lean own-build crosses over.

Now the cheap-to-build pieces pay back inside a reasonable window. You internalize the components that are inexpensive to build and expensive to rent. You keep renting the costly primitives. This is a partial move, not a full migration.

Scale

Higher volume still. More pieces clear the payback bar.

At this point, in-housing additional components makes sense one at a time. Each component gets its own payback calculation. Some flip to "build," some stay "rent." You're internalizing on a rolling basis as each piece crosses its own crossover.

Full vertical

Around 2,500-plus orders a month. Only here does building the entire clinical stack pay back.

This is where you replace the thin clinician-network API and the bundled platform with infrastructure you fully own. The $220,000 build finally makes sense, because the recurring savings now repay it inside the horizon and the per-order economics are decisively in your favor.

Four scenarios, four different right answers. The founder who picked "build" or "buy" on day one and committed would have been wrong in at least three of them. That's exactly why staged build vs buy beats the one-time fork.

The Staged Move: Rent the Bundle, Build the Layer You Keep

Here's the playbook I'd actually run.

Rent the expensive primitives now

Through the founding cohort, rent the bundled platform or a thin clinician-network API. Don't sink capital into the expensive primitives when the payback is five years out.

This is the same stance I take across nearly every stack: rent the primitives, build the business logic. The clinician network, the compliance plumbing, the payment rails, those are primitives. Pay someone else to run them until your volume says you should own them.

Build the thin orchestration layer from day one

This is the part founders get backwards. They rent everything early, including the orchestration, and then they're trapped when they want to swap vendors.

Staged architecture: rent primitives, own orchestration layer

Start building the thin orchestration and business-logic layer immediately. From day one. That's the layer you keep no matter which vendor sits underneath it.

The orchestration layer is your routing, your business rules, your data model, the logic that defines how your specific business works. It's cheap to build relative to the primitives, and it's the thing that's actually yours.

Then you internalize the expensive pieces only after volume justifies the one-time spend. Component by component, each clearing its own payback.

Here's the part that makes renting now safe instead of a trap: the orchestration layer is also what makes vendor-swapping cheap later. If your business logic lives in your own layer and the vendor sits behind a clean interface, swapping the bundled platform for your own build is a contained project, not a rewrite.

So renting the primitives early doesn't lock you in. As long as you own the orchestration, you can change what's underneath whenever the payback math says to. That's the whole staged build vs buy strategy in one move.

When You Should Skip Staging and Just Build

Staging isn't always right. I'd be lying if I said it was. There are three cases where you skip it and build immediately.

When to skip staging and build immediately

You already have the volume. If you're migrating an existing book of business and you're past the crossover on day one, there's nothing to stage. The payback window is already short. Build. Waiting to rent first just adds a migration you'll redo in six months.

The rentable option creates a risk you can't accept. In telehealth, this is PHI handling. If renting a primitive means letting a vendor touch protected health data in a way that creates a compliance or data-isolation risk you can't live with, the recurring savings math is irrelevant. You build the part that owns the risk, regardless of payback, because the alternative isn't "more expensive," it's "illegal or uninsurable." I covered the pace of this in standing up a regulated telehealth brand.

No vendor exists for your niche. If the thing you need to rent doesn't exist, you don't have a rent option. Building isn't a choice, it's the only path. Stage what you can rent, build what you can't.

And one honest caveat, because I've watched it happen. Cheap lean builds can still rot into maintenance debt if the orchestration layer is sloppy. "Cheap to build" doesn't mean "free to maintain." If you internalize a component early and wire it together carelessly, you trade a clean monthly invoice for a mess that eats engineering time every week. The savings on paper evaporate into firefighting.

Build the layer well or the payback math turns into a lie you told yourself.

How I'd Run This Decision for Your Stack

The build vs buy decision framework isn't a coin flip. It's a payback calculation run against a volume forecast, per component, staged over time.

Most founders fail it in one of two directions. They build too early and bleed capital chasing recurring savings that take seven years to repay. Or they rent forever and quietly overpay for years past the crossover where owning would have won.

Both mistakes come from comparing monthly numbers instead of running the payback. The monthly delta pulls you one way. The capital and the volume forecast usually tell a different story.

I model this exact crossover for clients across regulated and DTC stacks before a single line of code gets written. I figure out which pieces to rent now, which to build immediately, and which to internalize later as volume clears each component's payback. The output isn't a slide deck. It's a staged plan with the volume thresholds marked.

If you're staring at a build-vs-buy call right now and the monthly numbers are pulling you hard one direction, the payback math probably tells a different story. That's the conversation to have first, before you commit capital you can't get back.

Ready to bring AI leadership into your company?

I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.

Apply to Work Together