Direct answer
I score build vs. buy on total cost of ownership (the full multi-year cost, not just the sticker price), time-to-value, and strategic differentiation, and I treat "buy now with a build trigger later" as a real third option, not a temporary version of "buy." The framework holds for a game engine subsystem too, but the weights shift hard: real-time performance constraints and tight integration with the engine's core loop usually push toward build or a deep customization of a bought component, even when a backend service in the same situation would clearly say buy.
The framework
- Total cost of ownership: upfront build cost plus ongoing maintenance, versus subscription or license fees plus integration cost. Buy is rarely "free" after the sticker price; integration, data migration, and vendor management all cost real engineering time.
- Time-to-value: how fast each option gets you to a working, shippable state.
- Strategic differentiation: does this capability directly differentiate the product, or is it commodity infrastructure everyone needs. The more it's the former, the more building (and owning the roadmap) is worth paying for.
- Lock-in and exit cost: how hard is it to leave a vendor later, and does the vendor's roadmap risk diverging from what you need.
I put these into a simple weighted score so the trade-off is explicit rather than argued from vibes, rather than leaving each criterion as a separate, incomparable argument.
Worked example
Say a team is choosing between building an internal capability and buying a vendor product, with these inputs on a 0-10 scale (higher is better for that option):
| Criterion | Weight | Build score | Buy score |
|---|
| Cost (lower cost scores higher) | 40% | 3 | 7 |
| Time-to-market (faster scores higher) | 40% | 3 | 9 |
| Strategic differentiation | 20% | 8 | 3 |
Build=0.4(3)+0.4(3)+0.2(8)=1.2+1.2+1.6=4.0
Buy=0.4(7)+0.4(9)+0.2(3)=2.8+3.6+0.6=7.0
Buy wins on the initial score. I don't stop there, though: I set an explicit trigger for revisiting, for example if strategic differentiation is later assessed at 7 or higher and the cost gap closes within a defined payback window, that's the signal to build. That turns a one-time decision into a standing policy instead of a decision that quietly goes stale.
How the game engine case changes the answer
The same criteria apply, but two of them move a lot. Time-to-market for a bought subsystem often looks fast on paper but hides a large hidden integration cost: a third-party rendering, physics, or VFX tool has to slot into the engine's frame budget, asset pipeline, and existing tooling, and a mismatch there can cost more engineering time than building the narrower thing you actually need. Cost also shifts, since game middleware often comes with per-seat or per-title licensing and sometimes runtime royalties that compound with scale in a way a typical software as a service subscription doesn't. And lock-in is sharper: proprietary asset formats and pipeline dependencies from a bought tool can be more expensive to migrate away from than a backend vendor's API, because the whole content pipeline gets built around them. A team choosing between building or buying a VFX graph editor for its engine, for instance, is really weighing "commodity enough to trust a vendor's roadmap" against "core enough to the game's visual identity that owning it fully pays for itself," which is the strategic-differentiation axis doing more work than the cost axis.
Where this generalizes
The same weighted framework applies whether the thing under debate is an internal engineering tool, an analytics or observability stack, a feature store or model registry, or a database choice being decided mostly on service-level agreement guarantees versus cost. Two variants are worth naming explicitly because they flip the framework's direction: negotiating a multi-year exclusive vendor contract adds a lock-in cost that should be modeled explicitly as a negative weight on the buy side, not treated as a footnote; and open-sourcing an internal component you already built is the build-vs-buy question in reverse, where the "cost" is ongoing maintenance burden for external users and the "benefit" is community leverage and hiring signal, not revenue.
Trade-offs and pitfalls
- Scoring only the sticker price. The build side's maintenance cost and the buy side's integration and lock-in cost are usually the parts that get underestimated, not the headline numbers.
- Treating "buy" as permanent. Setting no revisit trigger means the decision never gets re-examined even after the strategic picture changes.
- Cutting corners to hit a deadline instead of making the trade-off explicit. Cutting automated test coverage to hit an eight-week deadline is a real build-vs-buy-adjacent trade-off (build fast and thin vs. build right and slower); naming it as a deliberate, documented trade-off is different from letting it happen by default.
- Applying a backend service's weights to a performance-critical or pipeline-integrated subsystem without re-deriving them. The framework is the same; the inputs are not, and skipping that re-derivation is how teams end up with a vendor tool wedged awkwardly into a frame budget it was never designed for.
