Creating an internal tool with coding agents has become much faster, but data from the Future of Platform Engineering 2026 report indicates that ease of building does not necessarily mean having a clear vision. Among 379 platform engineering professionals, teams that relied on building from scratch for most of their features were about 3.5 times more likely to consider the lack of a clear strategy an obstacle.
This finding does not prove that building from scratch is the wrong decision, but it reveals a connection between how platform capabilities are provided and how clearly teams understand the direction in which they are working.
Off-the-Shelf Tools Are the Most Common Option
Some 51.3% of respondents said that using a ready-made foundational tool was their primary approach to supporting platform features, compared with 31.2% who relied on existing templates and 17.5% who built from scratch. Tool reliance was higher among teams classified as high-performing, at 58.8%, compared with 47.8% for templates and 33.3% for building from scratch.
The exceptions appear in environments directly tied to a specific technical path, such as local development environments, one-click projects, and ephemeral environments. In these cases, templates may provide alignment with approved paths that general-purpose tools cannot easily offer.
Ephemeral Environments Are an Indicator of Platform Maturity
Teams that provided ephemeral environments were more likely to report a positive impact from AI on software delivery speed and stability, as well as on code coverage and cost control. Among teams that described the impact as highly positive, more than three-quarters used ephemeral environments.
However, this relationship does not necessarily mean that the ephemeral environment alone caused the improvement. Teams that provide them often operate within broader platforms containing multiple automated capabilities, which may make the platform’s breadth and maturity more important factors in absorbing the volume of changes produced by AI without sacrificing stability.
Why Does This Matter?
The most important practical change is that AI lowers the cost of writing code, but it does not eliminate the cost of owning it. A tool built quickly requires maintenance, upgrades, and governance, and may increase the operational burden as the volume of changes in the development pipeline grows.
The data supports this distinction: 57.9% of teams predominantly building from scratch said that the lack of a clear strategy was an obstacle, compared with 15.6% of teams relying on templates and 16.7% of teams using foundational tools. Build-from-scratch teams also used AI more often to modernize legacy systems and migrate languages, suggesting that some of this use is devoted to maintaining complexities the teams themselves created.
The Question Is Not Simply Build or Buy
Cost-benefit analysis was the most common reason for build-or-buy decisions, at 29.6%, followed by a preference for open source at 28.6%, an assessment of fit and requirements at 22.4%, a preference for commercial tools at 22.4%, and building to achieve fundamental differentiation at 16.3%.
The material offers two possible interpretations that the data does not resolve: strategy may precede the build-or-buy decision, or building itself may become a temporary substitute for a strategy that has not yet taken shape. The clearest editorial conclusion, however, is that the problem is not building from scratch, but adopting it by default without a specific reason. Unique capabilities should be built around the organization’s context, while tools that efficiently solve standardized problems should be bought or adopted, with the cost of maintenance and long-term dependence taken into account.