Platform Strategy: Build vs Buy

The architect owns the decisions that are expensive to reverse: which models and vendors to standardise on, what to build in-house versus buy, and how the stack fits together. Get these right and every team moves faster on a solid foundation. Get them wrong and you're locked into something brittle that costs more every quarter.

The core trade-off is build versus buy, and the useful test is differentiation. Buy what's a commodity or isn't your edge — you get speed, maintenance, security patching and compliance handled, at the cost of some control and a per-seat bill. Build what's genuinely core to your advantage, what off-the-shelf can't fit, or what data sensitivity forbids sending out. Most real stacks are hybrids: buy the model and the infrastructure, build the thin layer of prompts, data, retrieval and workflow that is actually yours.

Be honest about the true cost of building. The prototype is the cheap part; the expensive parts are evaluation, monitoring, security review, on-call, and the person who still has to maintain it in two years when they'd rather be doing something else. A rough multiple of three on your first estimate is not cynical. Equally, be honest about the true cost of buying: per-seat pricing at real headcount, the integration work, and the migration you'll pay for if you leave.

Design against lock-in deliberately, because in a market moving this fast the ability to change your mind is worth real money. Keep model calls behind your own interface so swapping providers is a contained change. Own your prompts, your eval sets and your data — those are the assets, not the vendor relationship. Prefer tools that export cleanly. And avoid building deep dependencies on a single provider's proprietary features unless the advantage is large and you've priced the exit.

Standardising has genuine benefits — shared expertise, negotiating leverage, one security review, consistent guardrails — so standardise on a default and allow documented exceptions rather than either mandating one tool for everything or letting every team choose freely. The first produces bad fits and quiet workarounds; the second produces a dozen contracts nobody is tracking.

Weight security and data terms heavily for anything organisational, because they're the constraints most likely to kill a choice late and most expensive to discover after adoption. Where does data go, is it retained, is it used for training, who are the sub-processors, what certifications exist, and is any of that actually in the contract?

Then run the decision on evidence rather than a pitch. This is exactly what the TIP Score dimensions are for — capability, value, security, integrations, maturity and momentum — with the trade-offs and the catch stated. Shortlist on those, then decide on a bake-off using your own real tasks, the same discipline from Level 2 applied to a bet with a bigger blast radius.

Finally, write the decision down and give it a review date. A short record of what you chose, what you rejected, why, and what would change your mind is the single most useful artefact you can leave behind — it stops the same argument recurring every quarter, and it tells you when the reasoning has actually expired rather than when someone simply got excited about something new.