The choice between building custom solutions and purchasing existing tools has long been treated as a straightforward engineering calculation. However, new research suggests that how platform teams make this decision reveals something fundamental about their organizational maturity. Among 379 platform professionals surveyed for the 2026 Future of Platform Engineering report, those whose primary approach is building from scratch reported significantly higher rates of strategic uncertainty compared to peers relying on templates or commercial tools.
The traditional build-versus-buy framing weighs developer time against integration overhead and the maintenance burden of custom solutions. Yet this calculus has shifted with the rise of coding agents. Tools that once required months of development can now be assembled in days, fundamentally changing the nature of the trade-off. As one respondent explained the reasoning: "Build what makes us unique, buy or adopt what's standard, and always consider long-term cost and lock-in." The problem is not that building takes effort—it is that maintaining what gets built still does.
Most Teams Buy and Choose Deliberately
Across platform features, using an underlying tool emerged as the dominant approach, selected by 51.3% of respondents. Building on existing templates accounted for 31.2%, while building from scratch represented 17.5%. High-performing teams showed an even stronger preference for tools, with 58.8% choosing this path compared to 47.8% using templates and 33.3% building custom solutions. This pattern suggests a maturity effect: as platform engineering practices stabilize, teams increasingly standardize on established tools rather than maintaining bespoke implementations.
The reasoning behind these choices reflects deliberate decision-making. When asked to explain their sourcing logic, respondents cited cost-benefit analysis most frequently (29.6%), followed by open-source preference (28.6%), fit-and-requirements assessment (22.4%), preference for commercial tools (22.4%), and building for core differentiation (16.3%). This alignment with domain-driven design principles—distinguishing core domains where custom work creates competitive advantage from supporting domains where it adds complexity—indicates that most teams are thinking strategically about where to invest engineering effort.
Notable exceptions exist where custom approaches dominate. Local development environments, one-click projects, and ephemeral environments skew toward templates rather than tools, because they must align with specific tech stacks and organizational golden paths that off-the-shelf solutions rarely accommodate. Teams offering ephemeral environments reported significantly higher positive impact from AI on delivery speed, stability, code coverage, and cost control. Among teams citing extremely positive AI effects, more than three-quarters had implemented ephemeral environments. This association likely reflects broader platform maturity: teams with ephemeral environments typically operate more comprehensive platforms with automated delivery capabilities, and this breadth correlates with stronger AI impact on outcomes.
The Build-from-Scratch Pattern
The strategy gap emerges sharply when examining teams by dominant build method. Teams building from scratch are approximately 3.5 times more likely to report lacking clear strategy as an obstacle (57.9%) compared to teams building from templates (15.6%) or using underlying tools (16.7%). This disparity suggests a fundamental disconnect between execution and direction.
AI adoption patterns reinforce this finding. Teams predominantly building from scratch lean more heavily on AI for legacy modernization and language migration work. Notably, this concentration reflects not higher overall AI adoption—their reported adoption rates, impact assessments, and expected effects match peers—but rather a specific pattern: teams building the most are using AI most intensively for maintenance work on custom-built features. The implication is clear: building custom solutions creates downstream maintenance obligations that AI is being deployed to manage.
Building First, Deciding Later
Two interpretations explain the strategy-building relationship. The first suggests that strategy precedes sourcing decisions: teams without clear direction lack the basis for deciding what to buy, so they build by default. The second proposes that building itself functions as strategy—a way to identify problems and demonstrate progress before the platform's purpose has fully crystallized. The available data cannot definitively establish which explanation holds, though Simon Wardley's mapping research describes a similar phenomenon: teams unable to see existing solutions tend to build custom answers to problems already solved elsewhere.
AI has compressed the timeline between conception and working prototype. An agent can generate a custom incident-management tool before anyone has established whether one is actually needed. This speed advantage masks a critical distinction: building has become easier, but owning what gets built has not. DORA's research indicates why this matters. Effective platforms provide capabilities while establishing boundaries on their use; in AI-assisted development, those guardrails may be more important than ever. Commercial tools arrive with these boundaries already defined; platforms assembled incrementally contain only the constraints someone explicitly added.
Regardless of causation, the relationship holds. Building from scratch is not inherently problematic. Building from scratch by default, without articulated reasoning, is where the strategy gap appears.
A Better Question Than Build or Buy
This finding does not argue for purchasing everything. The research confirms that some features require custom development around organizational context. Instead, it argues for deliberate buying. When teams build from scratch, that choice should rest on clear justification. When teams purchase tools, the reasoning is typically already evident: nearly all teams buy for well-defined platform components, and as agents generate more code, the value of tools that solve these problems well only increases.