Build vs Buy: A Decision Framework That Survives Contact With Sales

Every build-vs-buy decision framework survives the workshop where it’s presented. Most don’t survive the first time a persuasive salesperson gets forty-five minutes with your CFO. That’s not a framework problem. It’s a sequencing problem — the framework was applied after the preference had already formed.

By the time “should we build this or buy it” becomes an explicit question in most organisations, someone senior already has a preference, usually formed by a demo, a competitor’s stack, or a conversation at a conference. The framework that follows is not neutral analysis. It is a structure being used to justify a decision that already happened, dressed up as rigour after the fact. That’s not cynicism — it’s simply the order most of these conversations actually run in, and pretending otherwise is why so many build-vs-buy frameworks look sound on paper and fail the moment a vendor’s account executive gets time with the actual decision-maker.

The four questions that actually discriminate

A framework that survives contact with sales has to ask questions a good salesperson cannot answer for you, because the honest answer requires information only you have.

Is this core to how you compete, or is it plumbing? If the capability is genuinely how you win against competitors — the thing customers would notice if it were worse — building keeps the differentiation yours. If it is plumbing that every competitor needs identically, buying is almost always right, because building plumbing consumes engineering capacity that differentiation actually needs, for a capability nobody will ever notice you built well.

Does a real, working version already exist, or does the vendor’s demo show a future roadmap item? The gap between a demo and a shipped, working feature is where most buy decisions quietly become build decisions in disguise — you buy a platform for a capability that ships eighteen months later, and spend that eighteen months building the workaround you were trying to avoid building in the first place.

What does the data model actually need to carry, and can the vendor’s model carry it? This is the question a demo is specifically designed to prevent you from asking, because it requires you to already know your own requirements precisely enough to test them against the vendor’s schema rather than against the vendor’s presentation. A platform can look feature-complete in a demo and still be structurally unable to carry your specific obligation, and you will not discover that until you’re migrated onto it and past the point where undoing it is cheap.

What does exit actually cost, in both directions? Building carries a maintenance and key-person-dependency cost that compounds quietly for years. Buying carries a switching cost that is often deliberately obscured until you’re already committed — data export limitations, contractual lock-in periods, and integration work that only becomes visible once you try to leave. Neither cost shows up honestly in a first-year comparison. Both have to be priced for the full lifetime of the decision, not the first year of it.

Why the salesperson usually wins anyway

A capable salesperson’s entire job is answering the questions that are easy to answer well — feature comparisons, reference customers, implementation timelines — while the questions that actually discriminate never get asked, because they require internal homework the buying committee hasn’t done and the vendor has no incentive to prompt. The fix isn’t a better slide in the framework. It’s doing the homework — knowing your own data model requirements and your own differentiation boundary — before the vendor conversation starts, not during it. A framework applied after the demo is a rationalisation. The same framework applied before anyone takes a sales call is an actual decision.

Where this actually plays out

An iGaming operator evaluating a player-account-management platform is a clean version of this. The vendor demo shows unified player profiles, responsible-gambling controls, and cross-product session tracking — all genuinely impressive, all genuinely working in the demo environment. The question the demo is not built to help you ask is whether the platform’s player-identity model matches how your own sportsbook, casino, and any white-label skins currently define “the same player” — because if it doesn’t, you haven’t bought responsible-gambling compliance, you’ve bought a very polished interface sitting on top of the same fragmented identity problem you had before, and you won’t discover that until an audit or a real self-exclusion case tests it. A build-vs-buy framework applied properly here isn’t really asking build-versus-buy at all. It’s asking whether the buy option’s data model actually matches the regulatory obligation, which is a question no amount of demo polish answers.

Once buy wins, the next question is usually consolidation versus best-of-breed — a related but genuinely separate decision.

Once buy wins, the next question is usually consolidation versus best-of-breed — a related but genuinely separate decision.

Getting the data-model question right before any vendor conversation starts is the whole argument behind why the model comes before the tool. A technology control assessment can answer the core-vs-plumbing and data-model questions independently of any vendor relationship, before the decision gets made rather than after.