In 2025, 90% of organisations now have platform engineering capabilities. This shift marks a fundamental change in how technology organisations handle infrastructure and operations—part of the broader transition from DevOps culture to platform engineering structures.
Here’s why it happened: DevOps told developers “you build it, you run it.” Nice idea on paper. But in practice, developers ended up juggling infrastructure, monitoring, security, compliance, and deployment on top of actually writing code. That created a wall of cognitive load.
Platform engineering fixes this by putting dedicated platform teams in charge of building Internal Developer Platforms. These IDPs give developers self-service infrastructure through standardised workflows called golden paths. Developers get what they need without drowning in YAML files and infrastructure complexity.
It’s a structural change in how teams handle infrastructure. Instead of spreading operational responsibilities across all your developers, you create dedicated teams that build platforms serving everyone else.
For SMBs running 50-500 employee companies, the Thinnest Viable Platform approach means you can do this with 2-3 people, not 20. This guide covers how platform engineering works, how it differs from DevOps and SRE, and how to implement it at SMB scale without creating complexity you can’t maintain.
What Is Platform Engineering?
Platform engineering is “the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organisations in the cloud-native era.”
The output? An Internal Developer Platform—a centralised system where developers access infrastructure through self-service mechanisms like custom CLIs, web interfaces, and APIs.
The goal is reducing cognitive load. 76% of organisations admit software complexity creates developer stress and productivity loss. Developers spend over 10 times more time reading and understanding code than writing it. Human working memory handles only four to five items at once. When you pile infrastructure management, security scanning, deployment pipelines, and monitoring on top of actual feature development, something’s got to give.
Platform engineering consolidates tool sprawl into coherent workflows. Instead of each developer managing 15-25 different tools across CI/CD, infrastructure provisioning, monitoring, security scanning, deployment, and configuration management, the platform provides integrated golden paths.
These golden paths are opinionated, well-documented, supported ways of building and deploying software. Think paved roads making common tasks easy.
The platform team treats developers as customers. They build incrementally. They focus on self-service and automation. Developers currently spend 30-40% of their time on tool management and infrastructure rather than building features. Platform engineering returns this time to creating business value. With this approach, organisations with 20-30 developers should consider implementing an Internal Developer Platform to streamline workflows and reduce operational friction.
Platform Engineering Differs from DevOps
Platform engineering creates dedicated platform teams building Internal Developer Platforms. DevOps is a cultural methodology.
DevOps removed the gap between development and operations teams through collaboration, automation, CI/CD pipelines, and improved communication. That was valuable. DevOps broke down silos, got automation culture going, and enabled continuous delivery. Understanding this historical context of DevOps evolution helps clarify why platform engineering emerged as a structural solution to cultural challenges.
But “you build it you run it” created an unintended consequence—every developer became responsible for infrastructure, operations, security, and monitoring. The cognitive burden becomes overwhelming.
The growing complexity of technologies and architectures paired with the expectation for developers to be responsible for it all proved to be a crippling combination for many organisations.
Experienced backend engineers ended up taking on infrastructure tasks and helping less experienced developers, which stopped them from focusing on developing features. This created “shadow operations”—informal ops work happening inside development teams because nobody else was doing it.
Platform engineering extracts infrastructure responsibilities from development teams and hands them to dedicated platform teams building IDPs. Instead of embedding ops skills in dev teams, you create separate platform teams serving development teams.
This is evolution, not replacement. Platform engineering industrialises DevOps cultural principles. Platforms codify DevOps best practices—automation, CI/CD, monitoring, security—into reusable tooling. DevOps establishes the cultural foundation and principles, while platform engineering provides the tangible infrastructure and tools to make those objectives happen.
Platform engineering tries to enable true DevOps by following a Platform as a Product approach, striking the right balance between maintaining developer freedom and finding the right level of abstraction.
DevOps vs Platform Engineering vs SRE: Key Differences
Three distinct but related disciplines tackle different aspects of software delivery and operations.
DevOps is a cultural methodology. It’s about collaboration between development and operations through automation, CI/CD, and improved communication. Teams share responsibility for both development and operations.
Platform Engineering is a discipline that builds Internal Developer Platforms. Dedicated platform teams provide self-service infrastructure to development teams. Centralised platform ownership.
Site Reliability Engineering is a practice focused on keeping production systems reliable and scalable through engineering principles applied to operations. SRE teams are responsible for how code is deployed, configured, and monitored, as well as availability, latency, change management, emergency response, and capacity management of services in production.
The team structures differ. DevOps embeds ops skills in dev teams. Platform engineering creates dedicated platform teams serving dev teams. SRE creates dedicated reliability engineering teams.
The scope differs too. DevOps targets broad cultural change across the delivery pipeline. Platform engineering focuses on infrastructure abstraction and developer experience. SRE specialises in production reliability and incident management.
These disciplines work together rather than compete. SRE teams benefit from platform-provided observability golden paths. DevOps culture enables platform team collaboration. Platform engineering provides infrastructure supporting SRE goals.
For SMBs, most companies can implement platform engineering with a 2-3 person platform team. Fewer can afford dedicated SRE teams. DevOps culture applies regardless of size.
Start with platform engineering at small scale. Add SRE practices as scale demands.
Why 90% of Organisations Adopted Platform Engineering in 2025
The DORA 2025 report found 90% of organisations now have platform engineering capabilities. Gartner predicts 80% of large engineering organisations will have a platform team by 2026.
Here’s what drove it.
Cognitive load crisis. Developers were expected to write code, manage infrastructure, monitor production, respond to incidents, and maintain security compliance all at once. Something had to give.
Tool sprawl epidemic. The average development team manages 15-25 tools across CI/CD, infrastructure provisioning, monitoring, security scanning, deployment, and configuration management. As organisations grow, developers face increasing cognitive burden juggling container orchestration and cloud networking expertise.
“You build it you run it” burnout. DevOps tried cultural change but created individual responsibility overload. Platform engineering provides a structural fix through dedicated platform teams.
YAML fatigue. Infrastructure-as-code proliferation—Terraform configurations, Kubernetes manifests, CI/CD configs—eats up 30-40% of developer time on non-feature work.
Gartner validation. Analyst predictions gave this executive-level legitimacy, speeding up decision-making. When analysts say 80% adoption is coming, executives pay attention.
Proven productivity gains. Early adopters reported 30-50% reduction in deployment time, 60-70% fewer ops tickets, and 2-3x faster onboarding for new developers.
DevOps tried cultural solutions—everyone does operations. Platform engineering provides structural solutions—dedicated platform teams. That’s why 93% of survey participants view platform engineering as beneficial.
To understand why adoption accelerated so fast, you need to understand what organisations are actually building—Internal Developer Platforms.
Understanding Internal Developer Platforms
An Internal Developer Platform is a centralised system providing self-service infrastructure capabilities. Developers access resources through standardised interfaces—custom CLIs, web portals, APIs.
An IDP covers the complete infrastructure system. The IDP is the backend infrastructure layer: orchestration, integrations, automation, and golden paths enabling developer self-service. A portal like Backstage is one possible interface sitting on top of this foundation.
Core IDP capabilities include:
- Infrastructure provisioning — compute, storage, networking
- Application deployment pipelines — automated build and deployment
- Observability tooling — logging, metrics, tracing
- Security and compliance automation — scanning, policies, auditing
- Documentation and discoverability — service catalogues, runbooks
The architecture pattern is an abstraction layer over existing infrastructure. Your IDP sits above cloud providers, Kubernetes, and CI/CD tools, presenting a unified, simplified interface to developers.
Self-service is the emphasis. Developers provision resources, deploy applications, and access logs without needing manual ops team intervention or ticket-based workflows.
Platform engineering enables self-service capabilities: developers provisioning infrastructure without waiting for IT, standardised patterns ensuring consistency and compliance, automated guardrails preventing security vulnerabilities and cost overruns, and a unified experience across cloud, on-premises, and edge.
Technology stays agnostic. IDPs abstract underlying tools. You can use Terraform or Pulumi for IaC, Jenkins or GitLab for CI/CD, Prometheus or Datadog for observability.
For SMBs, focus on 1-3 workflows rather than trying to cover 50+ capabilities. Pick deploy web app, provision database, access logs. Build those well. Expand based on what delivers value.
Golden Paths: Opinionated Roads Without Roadblocks
A golden path refers to an opinionated, well-documented, and supported way of building and deploying software within an organisation.
Netflix calls them “paved roads”—same concept, different name.
Golden paths are templated composition of well-integrated code and capabilities for rapid project development. They’re paved roads making common tasks easy.
Here’s a concrete example. Your “Deploy Python web app” golden path includes a Dockerfile, Terraform configs, CI/CD pipeline, monitoring dashboards, and log aggregation. All pre-configured. A developer runs one command, answers a few questions about the app name and environment, and gets a fully functional deployment pipeline.
Your “Provision PostgreSQL database” golden path includes IaC templates, backup configuration, security policies, and connection documentation. Again, pre-configured.
Golden paths should be optional, transparent, extensible, and customisable. They should be an optional way of building and deploying to allow and foster innovation with flexibility to drift from standard workflows.
Developers can deviate for legitimate edge cases needing custom configurations. Golden paths optimise for the 80% common scenarios. Include escape hatches—well-documented processes for when requirements go beyond what templates can handle.
The cognitive load reduction is real. Developers follow golden paths for standard tasks without researching tool configurations, security requirements, compliance policies, or monitoring setup.
Platform engineering codifies best practices into self-service “golden paths”, reducing the mental overhead developers must carry.
Platform teams maintain golden paths—updating dependencies, fixing bugs, incorporating feedback. Developers consume them. That division of responsibility is what makes this work.
The benefits? Speed—deploy new code in minutes not days. Consistency—every service follows the same deployment pattern. Focus—developers spend time building features instead of wrestling with YAML, Terraform, or fragile bash scripts.
For SMBs, the key to implementing golden paths effectively is starting small.
Thinnest Viable Platform: Starting Small at SMB Scale
A Thinnest Viable Platform is a variation of the minimum viable product in classic product management.
The core principle: start with 1-2 workflows rather than a comprehensive platform covering all infrastructure needs. Expand based on demonstrated value.
For SMBs running 50-500 employee companies, you don’t have resources for 20-person platform teams building comprehensive IDPs. TVP lets 2-3 person teams deliver value quickly.
The anti-pattern is thick platforms trying to compete with commercial products, requiring extensive custom development and maintenance. Don’t build that.
Instead, compose existing tools. Use Terraform for IaC, GitLab CI/CD for pipelines, Prometheus for monitoring. Add lightweight integration code—scripts, APIs, basic web interfaces—creating cohesive toolchains.
Teams focus on creating the “thinnest viable platform”, or the smallest set of APIs, documentation, and tools needed to help a specific team release more simply and quickly.
A TVP could be as simple as a wiki page or as complex as a developer portal. Start small.
Red Hat’s 8-week MVP framework provides structure: Discovery (identify pioneering team), Integration (connect tools), Deployment (first golden path), Adoption Planning (rollout strategy).
For starting point selection, use force ranking. Evaluate teams by business value, pain points, and application complexity. Choose your pioneering team carefully. Pick one experiencing significant infrastructure pain, willing to provide feedback, building moderately complex applications—not your simplest or most complex project.
After deploying your first golden path, track adoption rate, ticket reduction, and deployment frequency. Those metrics tell you if this works before you expand scope.
Expansion strategy: add golden paths incrementally based on adoption metrics and developer feedback. Resist the temptation to build a comprehensive platform upfront.
The first rule: platforms must reduce cognitive load, never increase it.
Forming Your Platform Team: 2-3 People, Not 20
Team Topologies provides the framework. Four fundamental team types exist: stream-aligned teams delivering business value, platform teams building IDPs, enabling teams providing coaching, and complicated subsystem teams managing specialised components.
Platform teams are dedicated teams building and maintaining Internal Developer Platforms serving stream-aligned development teams.
At SMB scale, 2-3 person platform teams are sufficient for a Thinnest Viable Platform serving 50-500 employee companies. Enterprise scale requires 10-20 person teams. You don’t need that.
Team composition for a 2-3 person team:
- Infrastructure engineer — cloud, Kubernetes, IaC expertise
- Automation engineer — CI/CD, scripting, integration
- Developer experience engineer (optional) — documentation, templates, developer feedback
The interaction mode is X-as-a-Service. Stream-aligned teams consume platform capabilities without needing extensive collaboration or coordination.
The cognitive load boundary is clear: platform teams absorb infrastructure complexity, stream-aligned teams focus on business domain logic and feature delivery.
SMBs often start with 1-2 full-time platform engineers plus part-time contributions. Expand to a dedicated 3-person team as the platform matures and adoption grows.
Reporting structure matters. Platform teams should report to engineering leadership—CTO, VP Engineering—not to individual product teams. This ensures the platform serves all teams equally.
Success metrics: platform team measured by stream-aligned team satisfaction, adoption rates, reduced ops tickets, and deployment frequency improvements. Not infrastructure uptime alone. Your customers are developers. Their satisfaction determines your success.
Platform as a Product: Developers Are Your Customers
Treat your Internal Developer Platform as an internal product with stream-aligned developers as customers. Apply product management principles to platform development.
Start with customer discovery. Platform teams conduct developer interviews, surveys, and observation sessions identifying pain points, tool preferences, and workflow bottlenecks.
Establish feedback loops. Regular developer feedback sessions—monthly or quarterly—gathering input on golden path usability, missing capabilities, and documentation quality.
Track adoption metrics: golden path usage rates, self-service infrastructure requests, developer satisfaction scores (NPS or similar), and ticket volume trends.
Prioritise your roadmap based on developer pain points and business value, not infrastructure team preferences or technology trends. By offering golden paths to developers, platform teams can encourage them to use the services and tools preferred by the business.
Internal marketing matters. Platform teams actively promote capabilities through demos, documentation, and onboarding sessions. Don’t assume developers will discover features on their own. They won’t.
Iterate rapidly on golden paths based on developer feedback. Be willing to deprecate unused features and pivot based on actual usage. If nobody uses a capability after six months, kill it.
Measure success by customer satisfaction and adoption, not technical sophistication or feature count.
Avoid the build-trap. Don’t build comprehensive platforms speculatively. Focus on solving demonstrated developer pain points with minimal viable solutions.
Justifying Platform Engineering ROI to Executives
The executive value proposition: platform engineering reduces costs through consolidation, accelerates delivery through reduced cognitive load, and improves retention by addressing developer burnout.
Cost savings come from four categories:
- Tool consolidation reducing licence sprawl
- Reduced ops tickets freeing operations capacity
- Faster onboarding reducing time-to-productivity for new hires
- Infrastructure standardisation reducing cloud waste
Competitive advantage: faster delivery velocity and improved developer experience attract and retain engineering talent in competitive markets.
Investment requirements for SMBs: 2-3 full-time engineers (£150k-£300k annual salary costs) plus tooling and cloud costs. Payback period typically runs 6-12 months through productivity gains.
Measurement framework: track DORA metrics (deployment frequency, lead time, change failure rate, recovery time), ops ticket volume, developer satisfaction scores, and onboarding time.
Reference Gartner’s prediction that 80% of large engineering organisations will have a platform team by 2026. This analyst validation gives you executive-level legitimacy and peer comparison.
Transitioning from DevOps to Platform Engineering
Use a parallel track strategy. Implement platform engineering alongside existing DevOps practices rather than big-bang replacement. Demonstrate value before mandating adoption.
Start by identifying your highest-pain workflow for a platform engineering pilot. This is often the deployment pipeline or database provisioning golden paths.
Choose your pioneering team carefully. Pick one experiencing significant infrastructure pain, willing to provide feedback, building moderately complex applications. Not your simplest project. Not your most complex. Somewhere in the middle.
Use the 8-week MVP framework described in the TVP section to deploy your first golden path from discovery to deployment. Then iterate and expand based on adoption metrics.
Don’t force adoption. Make golden paths obviously better than manual workflows through reduced effort and cognitive load. Adoption follows value demonstration.
Some DevOps engineers transition to platform team roles building IDPs. Others remain in stream-aligned teams consuming platform capabilities. Both paths are valid.
Expand incrementally. Add golden paths one workflow at a time based on demonstrated adoption and developer feedback. Don’t try to build a comprehensive platform upfront.
Maintain cultural continuity. Keep DevOps cultural principles—automation, collaboration, continuous improvement—while evolving organisational structure to dedicated platform teams.
Frame communication as evolution building on DevOps success, not replacement or criticism. Acknowledge DevOps achievements while addressing structural limitations through platform engineering.
Technology Choices: Backstage, Humanitec, or Custom?
Three primary approaches exist: open-source portal frameworks like Backstage, commercial platform engineering platforms like Humanitec and Kratix, and custom integrations of existing tools.
Backstage is Spotify’s open-source developer portal framework providing service catalogue, software templates for golden paths, documentation, and a plugin ecosystem. It’s the most popular IDP frontend.
Backstage strengths: large community, extensive plugins, free core platform, software templates enable golden paths, highly customisable.
Backstage challenges: requires engineering effort to deploy, maintain, and customise. It’s primarily a developer portal—frontend—requiring backend infrastructure integration.
Humanitec is a commercial platform engineering platform providing application configuration management, environment management, and deployment automation. It reduces custom development.
Humanitec strengths: faster time-to-value, managed service reducing platform team maintenance, built-in workflows, score (configuration) and drivers (integrations) architecture.
Humanitec challenges: commercial licensing costs, vendor lock-in considerations, less customisable than open-source alternatives.
Custom approach integrates existing tools—GitLab CI/CD, Terraform Cloud, Datadog—with lightweight glue code. This aligns with Thinnest Viable Platform philosophy.
Custom strengths: leverage existing tool investments, maximum flexibility, avoid new tool adoption overhead.
Custom challenges: requires platform team engineering effort, maintenance burden, potential inconsistent developer experience across workflows.
For SMBs: start with custom integration of existing tools using the Thinnest Viable Platform approach. Evaluate Backstage if you need a developer portal. Consider commercial platforms if platform team capacity is limited.
Decision framework: evaluate your existing tool investments, platform team capacity, customisation requirements, and budget constraints.
FAQ Section
What is the difference between a platform and a developer portal?
A platform—Internal Developer Platform—covers the complete self-service infrastructure system including deployment automation, resource provisioning, and observability. A developer portal like Backstage is one possible frontend interface to an IDP, focusing on documentation, service catalogues, and software templates. Think of the platform as the engine, the portal as the dashboard. You can have a platform without a portal, but a portal without underlying platform capabilities is just documentation.
Do I need Kubernetes to do platform engineering?
No. Platform engineering is about providing self-service infrastructure capabilities regardless of underlying technology. While Kubernetes is common in platform engineering implementations, particularly at larger scale, SMBs can build effective platforms using simpler technologies like managed cloud services—AWS ECS, Google Cloud Run, Azure Container Apps—or even traditional VMs with good automation. Choose technologies matching your team’s expertise and scale requirements, not industry trends.
How do I measure platform engineering success?
Track four categories. (1) Adoption metrics—golden path usage rates, self-service infrastructure requests. (2) Productivity metrics—DORA measures including deployment frequency and lead time, plus onboarding time. (3) Efficiency metrics—ops ticket volume reduction, infrastructure cost optimisation. (4) Satisfaction metrics—developer NPS scores, platform team feedback surveys. Don’t just measure technical metrics like uptime or infrastructure capacity without connecting them to developer productivity and satisfaction.
Can I implement platform engineering with existing tools?
Yes, this is the recommended Thinnest Viable Platform approach. Compose existing tools—Terraform for IaC, GitLab for CI/CD, Datadog for monitoring—with lightweight integration code including scripts, APIs, and basic web interfaces rather than building comprehensive custom platforms. Most SMB platform engineering success comes from making existing tools easier to use through golden paths and self-service interfaces, not replacing tools entirely.
What is the difference between golden paths and guardrails?
Golden paths are opinionated, supported workflows making common tasks easy—paved roads developers can follow for standard scenarios. Guardrails are restrictions preventing certain actions—blocking alternative approaches. Platform engineering focuses on golden paths (making good choices easy) over guardrails (preventing bad choices). Golden paths should include escape hatches for legitimate edge cases where templates don’t fit requirements.
How long does it take to implement platform engineering at SMB scale?
Realistic timeline: 8 weeks for your first golden path covering one workflow like deployment or database provisioning, then incremental expansion adding 1-2 golden paths every 2-3 months based on adoption and feedback. Full platform maturity serving most development workflows typically requires 12-18 months. Don’t try big-bang comprehensive platforms. Demonstrate value quickly with focused initial scope then expand.
For a complete overview of how platform engineering fits into the post-DevOps landscape, including the challenges that drove this transition and organisational patterns for successful implementation, see our comprehensive guide to the death of DevOps and rise of platform engineering.
