Platform vs Feature Decision Framework

Should You Build the Platform or Just Ship the Feature?

Somewhere around 2015, every product team started calling everything a "platform." A notification system became a "messaging platform." A settings page became a "configuration platform." An internal dashboard became an "analytics platform." The word lost all meaning.

But the underlying decision is real and consequential. When your team faces a new need — say, in-app messaging, or a recommendation engine, or an auth system — you have three paths: build a feature, buy a third-party tool, or build a platform that others can extend. Most teams default to building without rigorously evaluating the alternatives. That default is expensive.

The Hidden Cost of Building Everything

According to a 2023 Forrester study on build-vs-buy decisions in enterprise software, companies that default to building in-house spend an average of 3.2x more over five years than those who strategically mix build and buy. The initial build cost is just the tip. Maintenance, on-call, security patches, upgrades, documentation — these compound relentlessly.

The platform question is even trickier. Jeff Bezos's famous 2002 API mandate at Amazon — requiring all teams to expose their functionality through service interfaces — is often cited as proof that everything should be a platform. But people forget the context. Amazon had thousands of engineers, massive scale requirements, and a strategic vision to become a cloud provider. Your 15-person startup does not have the same calculus.

Building a platform when you should have shipped a feature is one of the most common forms of over-engineering. It feels like an investment in the future. In practice, it often means you ship six months late with an abstraction layer nobody asked for, while your competitor shipped a feature in six weeks and is iterating on real feedback. Ben Thompson has written extensively about this: platforms make sense when you have clear demand for extensibility from multiple consumers. If you're the only consumer, you've built a feature with extra complexity.

How This Prompt Helps

This prompt gives you a structured decision framework for evaluating whether to build a feature, buy a third-party tool, or invest in building a platform. It walks you through cost modeling (including ongoing maintenance), risk analysis, strategic alignment, and team capability assessment. The framework doesn't have a bias — it'll tell you to buy when buying makes sense and build when building is justified.

The output is a recommendation with explicit reasoning you can present to engineering leadership and stakeholders.

When to Reach for This

• Engineering wants to build an internal platform and you need to evaluate whether the investment is justified
• You're choosing between a third-party vendor and an in-house solution for a core capability
• Your team keeps rebuilding the same functionality across products and someone has proposed a shared platform
• You're facing a build-vs-buy decision with significant cost and timeline implications
• A new requirement has surfaced and you need to decide whether it's a feature, a product, or a platform play

What Good Looks Like

A good platform-vs-feature analysis includes a five-year total cost of ownership for each option (not just build cost), a risk matrix that accounts for vendor dependency, team capability gaps, and maintenance burden, and a clear recommendation with explicit criteria for when to revisit the decision. The best analyses also define what would need to be true for the other option to win — this builds confidence that you've genuinely evaluated both sides.

Sources

• Build vs. Buy: The Real Cost of Enterprise Software Decisions — Forrester
• The Bezos API Mandate and Platform Thinking — Stratechery (Ben Thompson)
• When to Build a Platform vs a Feature — The Pragmatic Engineer