Platform engineering has become the infrastructure conversation of 2025. At every conference, in every Slack community, across LinkedIn feeds and engineering blogs, the message is consistent: build an Internal Developer Platform, create golden paths, treat your developer experience as a product. The promise is compelling. Developers get self-service capabilities, security teams get standardized guardrails, and engineering leaders get velocity back.
But there's an assumption buried in this conversation that rarely gets examined. Platform engineering, as typically described, requires something most companies simply don't have: a dedicated platform team.
The numbers tell an interesting story. Over 60% of enterprises building on Kubernetes in 2025 have formed or plan to form a dedicated platform engineering team. Gartner predicts that 80% of engineering organizations will have one by 2026. These statistics sound like momentum, but look closer and you'll notice something important: these are enterprise numbers.
The typical ratio cited for platform engineering is one platform engineer for every 20 to 50 developers. For a 30-person engineering organization, that means dedicating one or two full-time engineers purely to building and maintaining internal tooling. For many Series A through C companies, this represents a significant portion of the engineering budget directed away from product development.
Then there's the tooling investment. A modern Internal Developer Platform often involves Backstage for the developer portal, Crossplane or Terraform for infrastructure provisioning, ArgoCD or Flux for GitOps, plus the integration work to make these tools talk to each other and your existing systems. Each tool requires learning, configuration, and ongoing maintenance. The platform itself needs product management discipline because without someone actively gathering developer feedback and iterating on the experience, internal tools tend to calcify and frustrate rather than enable.
This is the hidden assumption of platform engineering: that you have the headcount, budget, and organizational patience to build infrastructure for your infrastructure. For companies selling to enterprise customers or operating in regulated industries, the calculus gets even more complicated. You need platform engineering outcomes like compliance-ready deployments and audit trails, but dedicating engineers to build those capabilities internally means slower progress on the product features that actually differentiate your business.
Without a formal platform engineering approach, companies typically fall into one of two patterns, and neither works particularly well at scale.
The first pattern is what you might call ticket-ops. Developers submit requests for infrastructure changes, wait for the ops team to process them, and eventually receive what they asked for. In theory, this maintains control and consistency. In practice, it creates bottlenecks that throttle development velocity. Research suggests that developers lose 6 to 15 hours weekly to tool sprawl and context switching. When infrastructure changes require tickets and approval cycles, that number grows. The ops team becomes a constraint rather than an enabler, and both sides end up frustrated.
The second pattern is the opposite extreme: give everyone console access and let them figure it out. This approach feels faster initially. Developers can spin up resources when they need them without waiting for anyone. But over time, environments diverge. Staging stops matching production. Resources get created and forgotten. Security configurations vary between services. When something breaks at 2 AM, no one quite remembers how a particular service was configured or why. The cognitive load shifts from waiting for tickets to remembering tribal knowledge about infrastructure that exists only in someone's head.
There's a third non-solution worth mentioning: staying on a simple PaaS until you can't anymore. This works until you hit one of three walls. The cost wall arrives when your infrastructure bill starts including significant markup over the underlying cloud resources. The compliance wall appears when a customer audit requires your data to stay in your own cloud account, not a vendor's shared infrastructure. The control wall materializes when you need capabilities that the PaaS simply doesn't expose.
Here's the reframe that matters: you don't need a platform team. You need platform engineering outcomes.
Consider what a good Internal Developer Platform actually provides. Developers can deploy code without submitting infrastructure tickets. Environments stay consistent from development through production. Security and compliance guardrails are built into the workflow rather than bolted on afterward. Costs are visible and predictable. The infrastructure underneath is powerful enough to scale with the business.
None of these outcomes inherently require building custom tooling. They require having the right abstractions in place, whether those abstractions were built internally or adopted from a platform designed to provide them.
The mental shift here is subtle but important. Platform engineering as a discipline emerged because the DevOps promise of "you build it, you run it" overloaded developers with operational concerns. Development teams use an average of 7.4 tools, and the resulting context switching destroys focus and productivity. The solution isn't to build more internal tools. It's to reduce the number of concerns developers need to think about while maintaining the capabilities the business requires.
The alternative to building your own platform or living without platform engineering outcomes is to adopt a platform that delivers these outcomes out of the box.
This isn't a new category of software, but the framing has shifted. What used to be called "PaaS" now exists on a spectrum. At one end are hosted platforms that optimize for simplicity but require you to trust the vendor with your infrastructure, your data, and your ability to leave. At the other end are Kubernetes distributions that give you control but require significant expertise to operate.
The interesting middle ground involves platforms that abstract Kubernetes complexity while deploying into your own cloud accounts. This approach, sometimes called Bring Your Own Cloud, provides several advantages. Your data stays in infrastructure you control, which matters for compliance and customer trust. Your cloud costs are transparent because you're paying the cloud provider directly rather than through a markup. And if you ever need capabilities the platform doesn't expose, the underlying Kubernetes is there.
When evaluating platforms in this space, the questions that matter are practical ones. Can developers deploy without understanding Kubernetes? Are environments consistent by default? Does the platform handle SSL certificates, load balancing, and health checks without manual configuration? Can you meet compliance requirements like SOC 2, HIPAA, or FedRAMP without heroic effort? Is the pricing predictable, or does it scale uncomfortably as your usage grows?
Convox is one platform that takes this approach, providing a deployment workflow that abstracts away Kubernetes while installing directly into your AWS, GCP, or Azure account. The infrastructure runs in your environment, giving you the compliance posture of self-hosted infrastructure with the developer experience of a managed platform.
Some organizations genuinely need to build their own platform. If you have hundreds of engineers, highly specialized workflows, and the organizational commitment to treat internal tooling as a product, building may make sense. You probably already know if this describes your situation.
For everyone else, the question isn't whether to invest in platform engineering but how to acquire platform engineering outcomes most efficiently. Building requires dedicated headcount, ongoing maintenance commitment, and patience measured in years. Adopting requires evaluating options, managing a vendor relationship, and accepting some constraints on customization.
The honest answer for most mid-market companies is that adopting makes more sense. The engineers who would spend years building an Internal Developer Platform can instead spend those years building the product your customers actually pay for. The developer experience improvements that platform engineering promises can arrive in weeks rather than quarters.
This doesn't mean adoption is without tradeoffs. You're taking a dependency on a vendor's roadmap and support responsiveness. You're accepting their opinionated choices about how deployment should work. You lose some flexibility in exchange for not having to maintain the underlying complexity yourself.
But these tradeoffs exist for building too. Internal platforms depend on the engineers who built them, and those engineers eventually leave. Internal platforms encode opinionated choices that become harder to change over time. Internal platforms require maintenance that competes with product work for engineering attention.
The difference is that adopted platforms come with support teams, documentation, and communities of users who have solved similar problems. The maintenance burden is shared across everyone using the platform rather than concentrated in your organization alone.
Platform engineering emerged as a response to real problems. Developers drowning in operational complexity, infrastructure inconsistencies causing production incidents, security gaps arising from ad-hoc configurations. These problems deserve solutions.
But the solution doesn't have to be building your own Internal Developer Platform. The goal is better developer experience, faster shipping, and infrastructure that doesn't keep you up at night. If you can achieve those outcomes by adopting the right platform rather than building one, you've successfully implemented platform engineering even if you never hired a platform team.
The companies that thrive in the next few years won't be the ones with the most sophisticated internal tooling. They'll be the ones who found the fastest path to platform engineering outcomes and directed their engineering energy toward the things that make their products unique.
If you want to see what platform engineering without a platform team looks like in practice, Convox offers a Getting Started Guide that walks through installation and your first deployment. There's also a video series if you prefer to follow along visually. You can explore example applications in Rails, Node, Django, and other frameworks to see how it fits your stack. Console accounts are free, and you can install your first Rack in minutes.
