Build, buy, or rent: a decision framework

Every growing business hits the same wall. The number of SaaS subscriptions creeps up, the workflows stitching them together get more brittle, and eventually someone asks the question:

"Should we just build this?"

Sometimes the answer is yes. Often it's not. Here's the heuristic we use.

The three modes

Build — write custom software you own. Buy — purchase a SaaS product (one-time or subscription). Rent — use a SaaS product as glue, where you accept it could be ripped out tomorrow.

Most teams collapse "buy" and "rent" together. They're not the same thing. The mental model matters.

When to build

Build when all three are true:

1. The workflow is core to how you make money or hold customers.
2. There's no SaaS product that fits your shape well (or the closest ones cost more to bend than to write).
3. You can afford to maintain it — code, on-call, future features — for at least 3 years.

Examples we've built for clients: the booking-and-dispatch system for a home services company, an AI triage agent specific to a SaaS's product taxonomy, an internal pricing tool for a wholesaler.

Anti-example: don't build payroll. Don't build email. Don't build CRM unless you really know what you're doing.

When to buy

Buy when:

1. The workflow is important but not differentiating (payroll, email, accounting, CRM, helpdesk).
2. A well-known, well-funded product already fits 80%+ of your needs.
3. You're fine being one of many customers — you don't need it to bend to you.

Buy the boring stuff. The hours you don't spend re-inventing tax-rate tables go into the work nobody else can do.

When to rent (and why this matters)

Rent when:

1. You need a capability right now.
2. You suspect you'll outgrow the SaaS in 12–24 months.
3. The cost of switching later is acceptable — usually because you treat it as disposable glue.

This is the underrated category. A SaaS for scheduling now, knowing you'll replace it with your own workflow when the team triples. A no-code automation now, knowing you'll port the highest-volume flows to real code once they prove valuable.

The trap most teams fall into: they "buy" something that they should have only "rented." Then they marry it. Then they can't move off when they outgrow it.

A real example

A client came to us last year with 14 SaaS subscriptions tied to one core workflow. Total bill: $42k/year. The actual core of the workflow — the decision-making logic — wasn't in any of them. It lived in a shared spreadsheet that two people maintained by hand.

We built the core (the spreadsheet logic, now real software with audit trails) and kept four of the SaaS tools because they handled the boring stuff well. We retired the other ten.

Total cost the next year: $11k SaaS + a $35k build cost. Year two and beyond: $11k SaaS, zero build cost, and a system they own.

That's what the framework looks like in practice.

The 24-month test

When you're torn between build, buy, and rent on a specific tool, ask:

"Where do I want to be in 24 months with this capability?"

If the answer is "still using whatever's easiest right now," rent.

If the answer is "still using exactly this tool, but more deeply," buy.

If the answer is "I want this to be a real, deep, owned part of the business," build.

That's usually all you need.