The Build-vs-Buy Decision, Owned by the Technical PM

Build-vs-buy is a strategy decision wearing an engineering costume, and the technical PM is the only person in the room positioned to own it. Engineering will size the build; finance will size the invoice; only the PM can say whether the capability is where the product's differentiation actually lives. Get that framing wrong and you'll optimize a spreadsheet instead of a moat.

Quick Answer: Buy or partner for anything that's context — necessary but not differentiating (auth, payments, email). Build only what's core — the 10-20% of your system that customers would notice and competitors can't easily replicate. Score every candidate on core-vs-context fit, switching cost, time-to-value, and total cost of ownership before anyone estimates engineering hours.

Why This Is a Strategy Decision, Not an Engineering One

The direct answer: build-vs-buy is fundamentally about where your differentiation lives, not which option costs less on a spreadsheet. Engineering effort estimates answer "can we build it," not "should we," and conflating the two is how teams end up building commodity infrastructure while a competitor ships the feature that actually matters.

Geoffrey Moore's core vs. context framework, first laid out in Living on the Fault Line, remains the cleanest lens here. Moore's distinction: core activities are the ones customers pay a premium for and that differentiate you competitively; context activities are necessary to run the business but generate no competitive advantage no matter how well you execute them. A payroll system is context even at a payroll company's competitor — but the underwriting algorithm is core if you sell insurance.

The PM's job is to make that classification explicit before anyone opens a spreadsheet. Left implicit, the default answer is almost always "build," because engineers are hired to build things and rarely get rewarded for recommending a vendor. That default is expensive:

• Engineering time spent on context work is time not spent on core work — the true opportunity cost, not the visible line-item cost.
• A "not invented here" bias quietly reclassifies context as core to justify a build the team wants to do anyway.
• Vendors who've solved a context problem for hundreds of customers have almost always solved edge cases your team hasn't hit yet.

This is also where being credibly technical matters — you need enough fluency to sanity-check an engineer's effort estimate without becoming the estimator yourself, a balance covered in how technical is technical enough and in the broader case for why the role exists at all.

The Four-Factor Scoring Framework

A structured score beats a gut call because it forces the same four questions onto every candidate, whether it's an auth system or a recommendation engine. Score each factor 1-5 and weight core-vs-context fit heaviest — it should function as a near-veto, not just one input among four.

Core-vs-Context Fit

Ask: if a customer discovered this exact capability was outsourced, would they care? For auth, almost nobody cares — Okta, Auth0, and Clerk all sit behind login screens customers never scrutinize. For a recommendation engine that's the reason customers choose you over a competitor, they'd care a great deal.

Score it by asking three sub-questions:

1. Does this system encode proprietary data, algorithms, or domain knowledge no vendor has?
2. Would a competitor buying the same vendor product end up with a functionally identical capability?
3. Does improving this system directly move a metric customers explicitly pay more for?

Switching Cost and Reversibility

Every buy decision is also a lock-in decision, and lock-in is asymmetric — it's cheap to enter and expensive to exit. Jeff Bezos's well-known one-way vs. two-way door framing applies directly: a two-way-door decision (proprietary auth format, no data export, deep webhook coupling) should get far more scrutiny than a one-way door.

Score reversibility by checking, before signing anything:

• Can you export 100% of your data in an open, documented format?
• Does the vendor's API contract let you run a shadow/parallel system during migration?
• Is the integration point isolated behind your own interface layer, or does vendor-specific code leak into core business logic?
• What's the realistic engineering cost to migrate away, in months, if the vendor doubles pricing or shuts down?

A useful gut-check: if switching away would take a rewrite rather than a rip-and-replace behind an interface, you've built dependency, not flexibility — the same discipline used when owning an infrastructure roadmap and negotiating platform-level trade-offs.

Time-to-Value

Buying is almost always faster to a working state — that's the entire pitch of a managed service. But time-to-value cuts both ways: a fast buy that locks you into the wrong architecture can cost more time later than a slower build that fits.

Weight this factor by urgency, not preference. If a competitor already shipped the feature and you're losing deals over its absence, buy even a mediocre-fit vendor and replace it later. If there's no competitive clock running, let core-vs-context fit dominate instead.

Total Cost of Ownership

The direct answer: TCO is the 3-year all-in cost of each path, not the headline number either option leads with — vendor list price versus a first sprint's story-point estimate. Both headline numbers are systematically misleading in opposite directions.

Building nearly always looks cheaper in a first estimate because it counts only initial engineering hours and ignores maintenance, security patching, and the opportunity cost of what else that team could have shipped. Buying nearly always looks more expensive up front because the invoice is a single visible number competing against an invisible one.

Worked Example: Auth vs. Recommendation Engine

Running both scenarios through the same four factors makes the contrast concrete — and shows why the same team can reach opposite conclusions on two systems in the same sprint planning cycle.

Scenario A: Authentication

Authentication is close to a textbook context decision. Score it out:

• Core-vs-context: Context. No customer chooses your product because of a superior login flow; they choose it despite friction in login if the core product is good enough.
• Switching cost: Low if scoped correctly — modern auth vendors (Auth0, Clerk, WorkOS) support open standards (OAuth2, OIDC, SAML) and full user-data export, so migration is a project, not a rewrite.
• Time-to-value: Fast — days to weeks versus months for a hardened, security-audited in-house system.
• TCO: Buying wins clearly. The build path carries an ongoing, asymmetric tail risk: a security team dedicated to patching auth vulnerabilities forever, for a system that never differentiates you.

Verdict: buy. The only real judgment call is which vendor, and how tightly you isolate the integration behind your own interface so the two-way door stays closed.

Scenario B: Recommendation Engine

The recommendation engine that ranks content or products using your proprietary interaction data is close to a textbook core decision. Score it out:

• Core-vs-context: Core, assuming the ranking logic is why customers convert or return. If it's a commodity "customers who bought X also bought Y" pattern with no proprietary signal, it may actually be context — check this honestly before committing engineering years to it.
• Switching cost: A vendor recommendation engine locks in your training data and modeling approach inside their black box — a one-way door, since you can't easily extract "how it learned," only raw logs.
• Time-to-value: Slower to build well, but a mediocre vendor recommendation system live in week two can still underperform a well-tuned in-house one by month six.
• TCO: Building wins if — and only if — you have the proprietary data and ML talent to make it genuinely better than a vendor's generic model. Otherwise you're paying build-cost for a context-grade result.

Verdict: build, but only after confirming the proprietary-data test above; otherwise this quietly reclassifies as context and the auth logic applies instead.

The pattern across both: buy decisions should be reversible and buried in context; build decisions should be irreversible-by-design and reserved for core. The framework's real job is catching the cases where a team is about to do the opposite of both.

Where Prodinja Fits in This Decision

Once you've scored a candidate as "buy," the harder question is usually the dependency graph that decision quietly creates — what breaks downstream if the vendor changes terms, and what other systems now assume the vendor's data model. Prodinja's Systems Engineering module is built around causal-loop diagrams designed to help you map exactly those long-run dependencies: draw the vendor integration as a node, trace its feedback loops into your roadmap and data architecture, and see where a buy decision's lock-in would actually bite before you sign the contract, not after.

This is intended as a visualization aid for a decision you've already reasoned through with the scoring framework above, not a system that computes the decision for you — it's a way to make the second-order consequences of "buy" visible on a diagram instead of discovered eighteen months later.

Key Takeaways

• Score core-vs-context fit first and weight it heaviest — it functions as a near-veto on the other three factors, not an equal fourth input.
• Reversibility, not cost, is the real risk to manage — a cheap buy decision with a one-way-door lock-in can outweigh an expensive one that stays reversible.
• TCO always includes maintenance and opportunity cost, not just the headline build estimate or the vendor invoice — both headline numbers mislead in opposite directions.
• Auth is close to a textbook buy: context, reversible via open standards, fast, and cheaper on a 3-year TCO view.
• A recommendation engine is only a build if the proprietary-data test passes — otherwise it's context wearing a core costume, and the auth logic applies instead.
• Isolate every vendor integration behind your own interface layer so a two-way door doesn't quietly become a one-way door through leaked vendor-specific code.