Every platform capability forces the same uncomfortable question: should we build this, buy this, or assemble it from existing parts? Get the answer wrong and you'll either drown in undifferentiated toil or hand your roadmap to a vendor's sales team. Get it right consistently and the platform compounds.
Why the decision is hard
Platform teams are staffed with excellent engineers, which creates a systematic bias: everything looks buildable, and building is fun. Meanwhile, leadership often overcorrects the other way, treating "buy" as a risk-elimination strategy. Both instincts ignore the same truth — the platform's job is to concentrate effort where the organization is genuinely different and outsource everything else.
A practical framework
Run every significant capability through four questions:
- Is this differentiating? If the capability shapes how your organization uniquely delivers software — your compliance posture, your deployment topology — it's a build candidate. If it's commoditized (artifact storage, CI runners, secrets management), start with buy.
- What's the ten-year maintenance burden? Building means owning: upgrades, security patches, on-call, and eventual migration. Price that in honestly. A bespoke solution that takes two engineers to maintain had better create more than two engineers' worth of organizational leverage.
- Does the vendor's roadmap bend toward us? Buying isn't a snapshot, it's a subscription to someone else's priorities. Evaluate the vendor's direction, their extensibility model, and your exit cost — before signing.
- Can we assemble instead? Between build and buy lies the modern default: composing managed services and open source behind your own paved-road interface. You keep the developer experience coherent while the ecosystem does the heavy lifting.
The interface is the asset
The deepest insight in platform build/buy decisions: the durable asset isn't the implementation, it's the interface your developers depend on. Swap managed Postgres for self-hosted, or one CI vendor for another, and if the golden path doesn't change, the migration is a footnote. Own the interface; stay promiscuous about what sits behind it.
Decide once, review on a clock
Build/buy/assemble decisions decay. The market moves, your scale changes, yesterday's differentiator becomes tomorrow's commodity. Write the decision down with its rationale and revisit it annually. The teams that suffer most aren't the ones that chose wrong — they're the ones still defending a choice that expired two years ago.
Platform teams earn trust not by always building, but by demonstrably choosing where engineering effort creates lasting advantage.