Every platform decision begins with a feature matrix. Someone pulls together a spreadsheet comparing pricing tiers, API coverage, SLA commitments, SDK maturity, and whatever other first-order attributes seem relevant. The team debates for a week or two, picks the option that scores highest, and moves on to implementation. Six months later, the platform vendor changes its pricing model, deprecates the API version you built against, or gets acquired by a company whose incentives no longer align with yours, and the spreadsheet that justified the original decision has nothing useful to say about what happens next.
I keep seeing this pattern in the enterprise platform decisions we make at Mastercard and in the startup platform bets I evaluate through StartPath. First-order effects of a platform choice (today’s features, today’s price, today’s performance) are the easiest to measure and the least predictive of long-term outcomes. Second-order effects are what determine whether a platform bet was wise or reckless: the governance model that determines how the platform evolves, the concentration dynamics of its ecosystem, the talent pool available to operate it, the switching costs that compound as your integration deepens.
The Feature Matrix Trap
Feature matrices are useful as a starting gate, not a finish line. They reduce a multidimensional strategic decision to a set of checkboxes, and those checkboxes inevitably reflect the platform’s current state rather than its trajectory. A blockchain L1 that supports smart contracts, has low gas fees, and shows strong developer activity looks excellent on paper; the matrix captures none of the governance dynamics that will determine whether those gas fees stay low, whether the smart contract language evolves or stagnates, or whether the developer community fragments after the next contentious fork.
At the enterprise scale, the same trap manifests differently, albeit with equally consequential outcomes. A cloud provider’s feature set matters less than its roadmap alignment with your regulatory environment. A payments API’s throughput matters less than the vendor’s track record on backwards compatibility during major version upgrades. The features you evaluate in month one are table stakes; the constraints you fail to evaluate define your roadmap for the next year.
Technical Lock-in vs. Strategic Lock-in
Most teams think about lock-in as a technical problem: how hard it would be to rewrite the integration layer, migrate the data, and retrain the engineers. That framing captures the switching cost but misses the switching consequence.
Technical lock-in is the effort required to leave. Strategic lock-in is the cost of what leaving does to your product trajectory. A team deeply integrated with a specific blockchain’s smart contract language faces technical lock-in, since rewriting contracts for a different VM is expensive. But strategic lock-in runs deeper: their product design reflects the capabilities and limitations of that specific execution environment, their users have mental models shaped by that chain’s transaction semantics, and their go-to-market positioning is anchored to that ecosystem’s community and brand.
I’ve watched startups in the StartPath accelerator realize they could technically port their contracts to a different chain in a few months, only to discover that the port would invalidate their entire distribution strategy because their users came from the original chain’s community. The technical migration was feasible; the strategic migration was prohibitive. Understanding which kind of lock-in you’re accumulating matters more than measuring the size of either one in isolation.
Technical lock-in is the effort required to leave. Strategic lock-in is the cost of what leaving does to your product, your users, and your market position.
Governance as a Risk Vector
Platforms evolve, and their governance model rarely receives the weight it deserves in platform evaluation. A centrally governed platform can move fast, which is great when the changes align with your needs and catastrophic when they don’t. A decentralised governance model moves slowly, providing stability at the cost of responsiveness, but also introduces the risk of contentious forks that split the ecosystem you depend on.
In the blockchain space, governance risk is visceral. I’ve seen StartPath cohorts where founders built their entire product on an L1 that subsequently went through a governance dispute, leaving them stranded on one side of a chain split with half the liquidity and developer tooling on the other side. The technical fundamentals of the chain hadn’t changed; the social infrastructure around it had fractured in a way that no feature matrix could have predicted.
Enterprise platforms carry analogous governance risks, albeit with different mechanics. When a SaaS vendor gets acquired, its product roadmap becomes subordinate to the acquirer’s strategic priorities. When a cloud provider sunsets a service, the deprecation timeline is set by their business calculus rather than your migration readiness. The question to build into every platform evaluation: who decides how this platform evolves, and what are their incentives?
Ecosystem Concentration and Talent Dynamics
A platform’s ecosystem concentration shapes your operational risk in ways that compound over time. If the tooling ecosystem around a platform is dominated by one or two providers, you inherit their reliability as a dependency and their business decisions as constraints. A blockchain where one provider dominates the block explorer, another dominates the wallet library, and a third controls node hosting has centralised its failure modes around entities that sit outside the protocol’s own governance structure.
Talent availability is the second-order effect that surfaces latest and hurts most. Choosing a platform with a thin talent pool means every hire takes longer, every departure hurts more, and salary expectations reflect the scarcity. I’ve seen this across both enterprise and startup contexts: teams that picked the technically superior option discovered that recruiting engineers who could operate it was either ruinously expensive or flatly impossible within the timeline the business required. The platform’s capabilities are irrelevant if you can’t staff a team to build on them.
Evaluating Beyond the Spreadsheet
The evaluation framework I’ve converged on after watching both enterprise and startup platform decisions play out over years comes down to questions that feature matrices never capture. For governance: who controls the platform’s evolution, what are their incentives, and what’s the worst-case scenario if those incentives diverge from yours? For ecosystem: how concentrated is the tooling and infrastructure landscape, and what happens if the dominant provider fails or pivots? For talent: can you hire and retain the people you need to build and operate on this platform, and what does the talent market look like in two years rather than today?
For strategic lock-in: if you needed to leave this platform in eighteen months, what would you lose beyond the code? Would your users follow you? Would your distribution channels still work? Would your product design still make sense on a different foundation?
When Platform Risk Becomes Existential
There’s a threshold where platform dependency transitions from a manageable constraint to an existential risk, and most teams cross it without noticing. The threshold is a function of how much your product identity and market position are entangled with the platform’s trajectory rather than how much code touches the platform. A startup building a DeFi protocol on a specific L1 crosses that threshold the moment its users associate the product with that chain’s brand. An enterprise team crosses it when the platform dependency is embedded in contracts with customers who chose the product partly because of that platform integration.
The mitigation strategies are well-understood in theory: abstraction layers that isolate platform-specific code, multi-platform deployments that distribute risk, and contractual protections that constrain the vendor’s ability to change terms. In practice, every one of these mitigations has a cost that makes it easy to defer, and deferral compounds the very lock-in the mitigation was supposed to prevent. The teams I’ve seen navigate platform bets most effectively build the abstraction layer before they need it, accept the upfront cost of a thinner integration, and treat platform risk as a first-class architectural concern from the beginning.
Platform risk becomes existential when your product identity and market position are so entangled with the platform’s trajectory that you can’t separate them without rebuilding both.
The constraints you don’t evaluate in the first month define the roadmap you didn’t plan for in the next year. Every platform bet is a prediction about someone else’s future behaviour, and the teams that win evaluate the prediction itself, with all its uncertainty, rather than treating today’s feature matrix as a reliable proxy for tomorrow’s reality.