The build vs buy decision framework

Build vs buy isn't a technical decision. It's a strategic one. And most PMs get it wrong by defaulting to a preference instead of following a framework.

I've seen great builders want to build everything. I've seen risk-averse PMs want to buy everything. Neither is right. The decision lives in the intersection of four questions, and getting the order wrong means you end up solving the wrong problem.

Question 1: What's your actual constraint?

This one surprises people because the answer is usually "time," not "we don't know how to build it."

I was building CasaHunter. I could build the apartment scraper, the deduplication, the ranking. I had evenings and weekends. No time constraint. So I built.

At Payments Rescue at QubicaAMF, we inherited a system in crisis. 44 open issues, customers unhappy, the team scrambling. Time was the binding constraint. We didn't have six months to evaluate vendor options. We needed to stabilize. Build it was, or the product doesn't exist next quarter.

The reverse: when evaluating cashless payment providers, time wasn't the constraint. Money was. Comparing three providers in depth, vetting integrations, proof-of-conceptual pilots. That takes months. Our constraint was that we had to decide by Q3 and roll out by Q4. We had a budget to accelerate that timeline through pilots and dedicated partnership resources. Buy from the right partner made sense.

Not because we couldn't build. Because we didn't have time, and time was the expensive thing.

Question 2: Is this a core differentiator or commodity?

At Payments Rescue, reconciliation was a differentiator. Every customer complained about it. It was a reason centers considered canceling. So we built. We owned the entire flow.

But payment processing itself? We bought. Square's payment processing is a commodity. Thousands of companies use it. We were not going to process payments better than Square. We bought the commodity and differentiated on top of it.

CasaHunter: the ranking algorithm is a differentiator. That one I built. The scraping infrastructure? That's getting closer to commodity as more providers appear. But the ranking — that's where judgment matters. I own it.

The question saves you from status-symbol engineering, where building something expensive and complex feels like an achievement even though it's not worth differentiating on.

Question 3: What's the total cost of ownership?

This is where most PMs get blindsided.

"Building in-house costs us one engineer for 3 months. Buying costs €50K." Sounds like a clear win for building. Until:

• The one engineer is now the subject matter expert. They own the system forever.
• When it breaks (and it will), they drop everything to fix it.
• When the business wants to add a feature, that engineer is the only one who can do it.
• When that engineer leaves, knowledge walks out the door.

At QubicaAMF we discontinued OneCashless — an internal build we'd invested heavily in — and moved to Amusement Connect (a partner). The cost math was:

OneCashless (our build):

• Development: €150K already spent, sunk.
• Ongoing: one engineer, 30% of their time, €50K annually. That's recurring.
• Maintenance, customer support, feature requests: accumulated to maybe €100K annually.
• Risk: one engineer leaving meant six months to backfill + knowledge loss.

Amusement Connect (partner):

• Setup and integration: €40K, one-time.
• Annual licensing: €60K.
• 24/7 support included.
• New features are someone else's problem.

Over three years, building cost us €300K+ in labor (not counting capital spend) plus the risk of knowledge loss. Buying cost us €220K + less risk. We bought.

Question 4: Can you reverse this decision in 6 months?

This one changes everything.

If you buy a vendor tool and realize it's wrong, how hard is it to switch? With Amusement Connect, the integration was designed for reversibility. We could move to another provider in three months if we had to. Moderate switching cost, manageable risk.

If you build something and need to swap it for a vendor tool, what's the cost? You've already built to spec. You'd have to rebuild to the vendor's spec. The sunk cost is real.

CasaHunter's ranking system: I own it. If it stops working, I fix it myself. Switching to a third-party ranking service would cost me three weeks of refactoring. The decision is reversible.

Payments Rescue: we had to stabilize fast. We couldn't have said "let's buy from a vendor and see if it works" because we couldn't afford to wait three months to find out it doesn't. We were in a position where reversibility was a luxury. We built.

The reversibility question isn't "could we theoretically do this?" It's "could we do this given our current constraints and burn rate?"

The framework in order

1. What's the constraint? (Time, money, capability)
2. Is this a differentiator? (Yes = build, No = consider buying)
3. What's TCO over 3-5 years? (Including labor, risk, opportunity cost)
4. Is the decision reversible? (No = raise the bar for the decision. Yes = lower it.)

Get the order wrong and you solve the wrong problem. Miss the constraint and you solve a problem you don't have.

CasaHunter: I had time, the ranking is a differentiator, building is the only way to own it, and I can reverse it if I need to. Build.

OneCashless → Amusement Connect: we didn't have time for a multi-vendor evaluation, cashless is not our differentiator, the TCO of ownership was unsustainable, and we designed the switch to be possible in three months. Buy.

That's how the best decisions get made. Not from conviction. From constraint.

---

See it in practice: The build-vs-buy framework played out differently across three projects: Cashless System (buy), Payments Rescue (build), and CasaHunter (build). Each decision came down to a different constraint.