A small rubric for build vs. buy decisions

Build-versus-buy conversations get emotional quickly. Engineers do not want a fragile vendor dependency. Operators do not want a custom system nobody has time to maintain. Founders do not want to spend roadmap on plumbing. Everyone is partly right.

The useful question is not whether building or buying is better. The useful question is where the product creates leverage.

Build when the workflow is core

If the workflow is central to the product's differentiation, building can be worth it. Not because custom code is noble, but because the team needs control over behavior, iteration speed, data shape, and user experience.

A commerce company may buy payroll but build checkout logic. A support product may buy billing but build routing. A design tool may buy email delivery but build collaboration.

Core does not mean important. Payroll is important. It may still not be core.

Buy when the problem is mature

Mature problems often have boring, reliable vendors: payments, tax, email delivery, auth, logging, payroll, status pages, customer messaging. Buying can compress years of edge cases into an API and a contract.

The danger is pretending the vendor removes all work. Integration, permissions, data sync, support, pricing, and failure modes still belong to the product team. Buying changes the shape of the work. It does not make the work disappear.

Count maintenance honestly

The cost of building is not the first version. It is every bug, migration, compliance update, on-call page, and feature request afterward.

I like to ask who will own the thing in six months. If the answer is unclear, buying may be cheaper even when the first invoice looks expensive. If the answer is obvious and the system creates product leverage, building may be cheaper than negotiating around vendor limits forever.

Watch for one-way doors

Some decisions are easy to reverse. A documentation tool can be migrated. A small analytics layer can be replaced. A deeply embedded billing provider, authentication model, or data warehouse architecture is harder.

The more irreversible the choice, the more the team should prototype integration, export paths, failure modes, and pricing at scale before committing.

Use a four-part rubric

I score the decision across four questions:

• Product leverage: does this create differentiation or learning?
• Maturity: is the problem already solved well by vendors?
• Integration risk: how deeply will it shape product data and workflows?
• Maintenance shape: who owns it, and how often will it change?

The answer does not need to be mathematical. The rubric makes the tradeoff explicit enough for a team to disagree productively.

The default

My default is buy the mature commodity, build the workflow that makes the product meaningfully better, and keep exits visible when the decision is hard to reverse.

That default is not glamorous. It keeps the team focused on the parts of the product customers can actually feel.

The hidden question is operating cost

Build vs. buy conversations often get stuck on feature fit and price. Those matter, but they are not enough. The hidden question is operating cost: what will this decision require from the team every month after the launch excitement fades?

Buying can look cheap until integration, vendor limits, support paths, data ownership, and migration risk show up. Building can look expensive until the team realizes the problem is core to the product and every workaround will distort the experience.

I try to make the conversation less ideological. Build is not noble. Buy is not lazy. The right choice depends on where the product needs control and where it can accept leverage.

ControlWhere must we be specific?

User experience, data model, pricing logic, permission rules, or speed.

LeverageWhere can we rent maturity?

Commodity workflows, compliance surfaces, infrastructure, or admin tooling.

ExitHow hard is reversal?

Migration cost, contracts, data portability, and user retraining.

Start with the product layer

The first question is: how close is this capability to the product's promise?

If the capability is part of why users choose the product, I lean toward building or owning more of the experience. If it is supporting infrastructure, I lean toward buying unless there is a strong reason not to.

Examples:

• A commerce product may need to own checkout behavior but buy tax calculation.
• A support product may need to own triage workflow but buy email delivery.
• A design tool may need to own canvas performance but buy billing.
• A portfolio site can use a CMS service but should own its presentation layer.

The mistake is treating all features as equal. They are not. Some features are the product. Some are plumbing. Some are differentiators only for a year. Some are distractions wearing strategic language.

Score reversibility early

I want to know how easily we can change our mind. A reversible decision can move faster. An irreversible decision deserves more skepticism.

Reversibility includes:

• Can we export the data?
• Can we keep our URLs?
• Can we replace the vendor without retraining every user?
• Can we preserve analytics history?
• Can we migrate gradually?
• Are contracts short enough?
• Is the integration isolated?

If the answer is no across the board, the decision is heavier than it looks.

Watch for the customization trap

Buying a tool and then bending it into a custom product can be worse than building. The team pays vendor cost, integration cost, and workaround cost. The UI becomes a patchwork of embedded flows, awkward settings, and inconsistent language.

The warning sign is when the team says:

"We can use this vendor if we just add a custom wrapper, sync data both ways, hide half the UI, override the emails, and build our own reporting."

At that point, the buy option may only be buying the hardest parts badly.

The small-team version

For small teams, I use a harsher filter:

• Do we have the expertise to maintain it?
• Will this distract from the core product?
• Can the first version be simpler?
• Can we buy time now and replace later?
• Can we isolate the decision behind an adapter?
• What user-facing promise are we making?

Small teams can die from noble builds. They can also die from vendor-shaped products. The decision needs to protect learning speed without surrendering the parts of the product that matter.

The one-page recommendation

I like ending the discussion with a one-page recommendation:

Decision: build / buy / integrate / defer
Why this path:
What we are optimizing for:
What we are giving up:
Reversibility:
Review date:
Exit trigger:
Smallest useful next step:

The review date matters. Build vs. buy is not always forever. A smart buy can become a build after product-market fit. A custom build can become a vendor once the workflow becomes commodity. The team should know what would change the decision.

The real goal

The goal is not to be right in a philosophical sense. The goal is to make a decision that the product can afford. That means knowing where control matters, where leverage helps, and where the team is about to sign up for hidden maintenance.

A good rubric makes the tradeoff visible enough that people can disagree productively.

Red flags in vendor demos

Vendor demos are optimized for momentum. Everything works, the data is clean, and the happy path is rehearsed. I try to watch for the places where the demo avoids product reality.

Red flags:

• The demo cannot show permission edge cases.
• Export or migration is described vaguely.
• The product requires heavy configuration before value appears.
• The vendor says "you can customize that" too often.
• The integration depends on brittle two-way sync.
• The pricing model grows with the wrong usage metric.
• The UI language cannot match your product language.
• Support and incident response are unclear.

None of these automatically mean "do not buy." They mean the operating cost is not fully visible yet.

I like asking vendors practical questions:

• What happens when sync fails halfway?
• Can we export all data without a support ticket?
• Which parts of the UI cannot be customized?
• How do permissions map to our roles?
• Can we test this in a staging workspace?
• What is the common reason teams leave?

The last question is especially useful. Mature vendors know their limits. If they cannot name who should not use the product, the team should be careful.

For build decisions, I run the mirror version of the same review. What are we pretending will be easy? What maintenance are we ignoring? Which edge cases will become our responsibility forever?

The rubric is not anti-vendor or pro-build. It is pro-clarity. The team should know what it is buying, what it is building, and what cost arrives after launch.

A decision can age

The decision should include a review trigger. "We will revisit this if support tickets exceed a threshold." "We will revisit this if the vendor cannot support our permissions model." "We will revisit this after the third customer requests custom reporting."

That makes the decision less emotional. The team is not admitting failure if it changes course later. It is following the conditions it already named.

Build vs. buy decisions go wrong when they pretend to be permanent. Products change. Teams change. Vendor maturity changes. The rubric should help the team make a good decision for this stage and know when the stage has changed.

The review trigger also helps with team memory. Six months later, nobody has to reconstruct why the team bought the vendor or built the internal tool. The decision carries its own expiration conditions. That makes future change less political, less personal, and more practical for the whole team when priorities shift. The record protects the next decision.