In a Platform Roadmap Workshop, you’ll work with SUE over the course of one week to determine what your platform needs to deliver first.
Plan a Platform Roadmap Workshop · Platform Engineering at SUE
Platform Engineering: The Complete Guide
Platform engineering involves building and managing an internal platform that enables development teams to securely build, test, and deploy software on their own. The platform integrates infrastructure, pipelines, security, and observability through self-service and defined golden paths. It has become mainstream: according to the DORA 2025 report, 90% of organizations have an internal platform. Whether a platform works depends on the approach: treat it as a product, start with your developers’ biggest pain points, and measure whether it helps.
Contents
- What is platform engineering?
- Platform Engineering, DevOps, and SRE
- When is a platform worth it, and when isn't it?
- What's included in an Internal Developer Platform?
- Golden paths and guardrails
- Portal or platform?
- Build, assemble, or purchase
- The Platform Team
- Step-by-Step Guide
- Measuring Success
- AI and Platform Engineering
- Why Platforms Fail
- Frequently asked questions
The Five Decisions That Matter
-
Do you need a platform? Usually only when multiple teams are working to solve the same problems. → Section 3
-
What do you deliver first? The golden path for the most common task. → Sections 5 and 9
-
Build, assemble, or purchase? → Section 7
-
Who builds and manages it? A platform team with a product owner. → Section 8
-
How do you know if it's working? Measure adoption, turnaround time, and satisfaction. → Section 10
1. What is platform engineering?
Platform engineering involves designing, building, and managing an Internal Developer Platform (IDP): a set of tools, services, and conventions that development teams use on a self-service basis. A team that wants a new service selects a template and is provided with a repository, pipeline, environment, monitoring, and security settings. It rolls out without needing to submit a ticket to another team.
Gartner expects that by 2026, 80% of large software engineering organizations will have a platform team, up from 45% in 2022.
Key Concepts
-
Internal Developer Platform (IDP): everything the platform team provides to development teams, from infrastructure to pipelines.
-
Developer portal: the gateway to the platform, featuring a service catalog, documentation, and self-service options. Backstage is the best-known example.
-
Golden path: the recommended, automated route for a common task, such as starting a new service.
-
Guardrails: rules that the platform automatically enforces, such as security policies and cost limits.
-
Platform as a product: The platform has users (developers), a roadmap, and a product owner, just like software for customers.
-
Cognitive load: everything a developer needs to know beyond the application itself. A platform reduces that load.
2. Platform Engineering, DevOps, and SRE
| Concept | What It's All About | Relationship to Platform Engineering |
|---|---|---|
| DevOps | Culture and Work Style: Teams Build and Maintain Their Own Software | Platform engineering makes DevOps scalable, so that not every team needs to have all the infrastructure knowledge itself |
| SRE | Production reliability, with service level objectives and error budgets | SRE practices are often built into the platform: monitoring, alerting, and incident response processes |
| Platform Engineering | An in-house product that makes the work of development teams easier and safer | Builds on DevOps and SRE |
3. When is a platform worth it, and when isn't it?
- multiple teams are repeatedly solving the same infrastructure tasks;
- developers spend a lot of time on pipelines, environments, and tickets;
- pipelines, security settings, and tools vary by team;
- it takes a long time for a new developer to get their first change into production;
- During audits, you must demonstrate that every release meets the same requirements.
It usually isn't worth it if:
- you have one or two teams with a simple stack;
- you do not have the capacity to maintain the platform as a product, either on your own or with a partner;
- a managed PaaS or container service from your cloud provider already does everything your teams need.
4. What does an Internal Developer Platform include?
The portal is the front door; the platform is everything behind it. A developer sees the portal, but benefits most from the automation underneath it.
5. Golden paths and guardrails
A "golden path" is the route recommended and fully automated by the platform team. For example, a golden path for a new web service provides:
- a repository with a standard structure;
- a pipeline that includes tests, security scans, and a container image;
- a rollout to the test environment via GitOps;
- a dashboard and alerts;
- tags for cost allocation.
Guardrails enforce what should always be the rule: no containers running as root, mandatory resource limits, images only from trusted registries, and encrypted storage. A “golden path” is a recommendation: teams are allowed to deviate from it, but they must then take on the additional responsibility themselves. The more appealing the path, the less likely teams are to deviate from it.
6. Portal or platform?
Many organizations start with a developer portal like Backstage. A portal without effective automation behind it becomes nothing more than a catalog of links and tickets. Therefore, start with the golden path and add the portal once there’s enough to show. Backstage is open source and flexible, but requires in-house development resources to maintain. Commercial portals like Port and Cortex can be set up more quickly, though they offer less flexibility.
7. Build, assemble, or purchase
| Approach | What It Is | Goes well with | Please note |
|---|---|---|---|
| Build It Yourself | Integrate open-source components yourself, such as Backstage, Argo CD, and Crossplane | Large organizations with a dedicated platform team | A lot of maintenance; the expertise is concentrated among just a few people |
| Compilations | Combining commercial building blocks, such as a portal-SaaS, managed Kubernetes, and CI/CD as a service | Organizations that want to get started quickly and remain in control | License Fees and Multiple Vendors |
| Order | A platform-as-a-service solution, including management, such as SUE's Multistax | Software teams without their own platform expertise | Less freedom outside the platform |
Whatever you choose, stick to one platform. According to *State of Platform Engineering*, Vol. 4 (January 2026), 55.9% of organizations run more than one internal developer platform, resulting in duplicate management and differing standards.
8. The Platform Team
A platform team consists of platform engineers with expertise in Kubernetes, Infrastructure as Code, CI/CD, and security, as well as a product owner who determines what the platform delivers first. Start small: a team of a few engineers and a product owner can build the first golden paths. The book *Team Topologies* by Matthew Skelton and Manuel Pais describes the platform team as a team that serves development teams; those teams are the customers. For 24/7 management of the underlying clusters, you’ll need more people or a partner. See the Kubernetes guide, section 13.
9. Step-by-Step Guide
- Talk to developers and identify where software delivery is currently being slowed down—for example, the lead time from commit to production.
- Choose one common task that's particularly difficult, such as launching a new service or requesting an environment.
- Build the smallest platform that solves that task: the thinnest viable platform.
- Test it with one pilot team and make improvements based on their feedback.
- Measure the impact: adoption, turnaround time, and satisfaction.
- Expand to include more teams and more golden paths, and add a portal if there's enough to show.
- Treat the platform as a product: with a roadmap, releases, documentation, and support.
In the Platform Roadmap Workshop, you'll go through the first three steps in one week.
10. Measuring Success
According to *State of Platform Engineering* Vol. 4, 29.6% of platform teams do not measure the success of their platform. That’s why you should start measuring even before the first release. Without a baseline measurement, you won’t be able to demonstrate the platform’s value later on.
11. AI and Platform Engineering
Nearly 90% of tech professionals use AI in their work, and 94% of platform professionals say AI is crucial to the future of platform engineering. The DORA 2025 report describes AI as an amplifier: with a good platform, you deliver faster; with a messy platform, you make mistakes faster.
What this requires of the platform
-
AI assistants in the IDE and the pipeline will have the same safeguards as developers: scans, reviews, and policies.
-
AI agents that modify infrastructure or code operate through the platform, with their own identity, minimal privileges, and logging. Gartner cites identity and access management for AI agents as one of the security trends for 2026.
-
The platform provides models, GPUs, and vector databases on a self-service basis, so teams don't have to build their own AI stacks.
-
According to Gartner, no-code and vibe coding open up new attack surfaces. A "golden path" for AI-generated code keeps it within the same boundaries.
12. Why Platforms Fail
| Cause | How to Prevent It |
|---|---|
| Built without consulting developers | Preliminary interviews and a pilot team |
| Too much at once | Start with one golden path, then expand |
| Make use mandatory | Making the path so appealing that teams choose it on their own |
| No product owner | Someone who sets priorities based on what developers need |
| Multiple platforms side by side | One platform with one set of standards |
| Do not measure | A baseline measurement and fixed metrics from the start |
| Management underestimated | Capacity for upgrades, security, and support, or a management partner |
To find out why developers sometimes resist a new platform, read our blog post on adopting an Internal Developer Platform.
13. Frequently Asked Questions About Platform Engineering
All frequently asked questionsDevOps is a culture and way of working in which teams build and run their own software. Platform engineering makes this feasible at scale: a platform team provides the tools and automation, so that not every team needs to have all the infrastructure knowledge itself.
An Internal Developer Platform (IDP) is the set of tools, services, and automation that development teams use on a self-service basis to build, test, and deploy software. It often includes a developer portal, golden paths, CI/CD, Kubernetes, security policies, and observability.
Backstage is an open-source framework for developer portals, originally developed by Spotify and now a project of the Cloud Native Computing Foundation. It offers a service catalog, templates, and plugins. It is flexible, but requires in-house development resources to set up and maintain.
No, but it's the most commonly used foundation because Kubernetes standardizes deployment, scaling, and recovery. A platform can also run on managed container services or serverless infrastructure. Learn more in the Kubernetes guide.
Four metrics from the DORA study for measuring software delivery: deployment frequency, time from commit to production, the percentage of changes that lead to an incident, and recovery time after an incident. They show whether a platform makes delivery faster and more stable.
Adoption by developers, continuing to maintain the platform, and demonstrating its benefits. Having multiple platforms running side by side and a platform designed without input from developers are the most common causes of problems.
What should your platform provide first?
What should your platform provide first?
In a Platform Roadmap Workshop, you’ll work with SUE over the course of one week to determine what your platform needs to deliver first.
Plan a Platform Roadmap Workshop · Platform Engineering at SUE
* required