Sometime in late 2022 the term "platform engineering" migrated from a niche operations discipline into the standard vocabulary of every European CTO deck. Gartner placed it on the Hype Cycle in 2023 and projected that eighty percent of large software-engineering organisations would establish platform teams as internal providers by 2026.1 The phrase has done its work as a rallying point. It has done less work as an organising principle. What it actually looks like inside a typical mid-sized Swiss enterprise tends, on inspection, to diverge sharply from what the term promises.
This is not a failure of effort. It is a failure of definition. The Team Topologies book2 — the closest thing the field has to a canonical text — distinguishes carefully between an operations team, an infrastructure-tooling team, and a platform team. The last is defined by treating internal developers as customers and the platform as a product. Most organisations describing themselves as platform-engineering shops have built the second. The distinction is not pedantic; it determines what the engineering organisation can actually do with the investment.
The four stages of platform maturity
The Humanitec State of Platform Engineering reports3 and the CNCF Platform Engineering Working Group documentation4 both converge on a four-stage maturity model. Calibrated against publicly reported European engineering organisations and against what is visible in CNCF and Backstage adoption metrics, the rough distribution across mid-sized Swiss enterprise software organisations looks approximately as follows. These are estimates, not measurements; the data is not publicly available at country granularity.
Stage one: shared scripts and good intentions. Someone on the infrastructure team has written Terraform modules. There is a shared Helm chart repository. A small number of internal engineers know how to use the deployment CLI. There is a Slack channel called #devops-help where one or two senior SREs answer questions between incidents. There is no dedicated platform team. There is no internal developer portal. This is not platform engineering. It is tribal knowledge with a Git repository — and the bus factor is one. Roughly a third of the mid-sized Swiss organisations one might survey sit here, with the proportion higher in firms below seventy-five engineers total.
Stage two: centralised tooling without product thinking. A real investment has been made. A platform team exists. Kubernetes runs. Backstage may even have been deployed.5 But the platform was built top-down — mandated by an architecture board, often without sustained input from the engineers it was supposed to serve. The "golden paths" feel, in practice, more like golden cages. Developer adoption hovers below fifty percent. The actual delivery work routes around the platform through shadow-tooling. The platform team is technically capable and organisationally underused. This is the most populous stage in larger Swiss enterprises — banks, pharma, insurers, the federal administrations — and the most diagnostically dangerous, because the visible investment masks the absence of impact.
Stage three: platform as a product. A meaningfully smaller cohort has internalised the Team Topologies definition. They have product managers — or, at minimum, product-minded engineers — running the platform. They track adoption metrics. They do user research with their own developers. They measure time-to-first-deploy for new services as a key performance indicator. They publish a roadmap their internal customers can read. The unlock is not the tooling. It is the obsession with developer experience as a measurable outcome.
Stage four: full internal developer platform. Almost no homegrown Swiss organisations are here. The platform abstracts infrastructure entirely; developers declare intent ("I need a service that handles 10k requests per second with a PostgreSQL backend and meets our regulated data-handling baseline") and the platform provisions, scales, secures, instruments, and compliance-checks the resulting service automatically. A handful of global companies with Swiss engineering offices are approaching this. Most domestic Swiss companies are not — and most do not need to be. Stage three delivers approximately eighty percent of the value of stage four at perhaps a quarter of the investment.
Why Switzerland specifically lags
Three structural factors slow the transition from stage two to stage three for Swiss organisations specifically.
Regulatory caution. Financial and healthcare-adjacent firms — a disproportionate share of the Swiss enterprise software population — default to control over autonomy. Platform engineering, done correctly, requires trusting developers with self-service deployment, secret management, and infrastructure provisioning inside well-defined guardrails. That is a cultural shift many compliance teams resist by reflex. The shift is achievable — Swiss firms have done it in regulated environments — but it requires the platform team to invest as much in compliance-as-code as in developer experience, and to bring the compliance function into the platform conversation early. FINMA Guidance 08/2024 on AI governance and operational resilience6 has, paradoxically, helped this conversation by making it easier to frame platform self-service as a control mechanism rather than a risk.
Small team sizes. A dedicated platform team is structurally hard to justify when the total engineering organisation is thirty people. The return-on-investment maths does not begin to work until roughly fifty to eighty engineers, at which point the time spent by every engineer not having a platform exceeds the cost of the team that would build one. A meaningful share of Swiss software companies sit below that threshold and reasonably defer the investment. They should not, however, defer the thinking: the lightweight scripts, conventions, and golden paths built between thirty and eighty engineers are precisely what becomes the platform team's first product when the organisation crosses the threshold.
Outsourcing legacy. A surprising proportion of Swiss enterprises still outsource significant portions of their development work, particularly in finance, insurance, and pharma. Building an internal developer platform when a substantial fraction of the developer population are contractors rotating every twelve months is a structurally different — and harder — problem than the standard Team Topologies model. The platform has to be self-explanatory in a way that internal-only platforms can defer. Documentation, onboarding flows, and learn-by-doing examples carry more of the operational weight.
What actually moves the needle
The pattern across the organisations that have successfully transitioned from stage two to stage three has remarkably little to do with the choice of tooling. Backstage, Port, custom internal portals, even well-organised README files have all served as the substrate. What distinguishes the transitions that worked from those that did not has roughly four components.
Stop buying tools; start measuring developer experience. Survey internal developers quarterly. Track lead time for changes, deployment frequency, time-to-first-deploy for new services, mean time to recover. The DORA four metrics, with the addition of developer-satisfaction signal, are the closest thing to a consensus measurement framework.7 What cannot be measured cannot be improved; what is not improved is, in this category, generally regressing under pressure from other priorities.
Build one golden path, not a whole platform. The most reliable failure mode is to attempt platform-completeness from day one and ship a half-built version of everything. The pattern that succeeds is the opposite: identify the most common workload type — for most Swiss enterprise applications this is a REST or gRPC service on Kubernetes with a relational database — and make that one path stupidly easy to use. Then expand outward, golden path by golden path, treating each as a discrete product launch.
Hire — or grow — a product-minded platform lead. The single most predictive variable for whether a platform team transitions from stage two to stage three is the disposition of its lead. Engineers who love Kubernetes will build well-engineered Kubernetes-shaped artefacts. Engineers who love making other engineers faster will build well-adopted platforms. These are different skill sets and different psychologies. The lead-hire decision is the operating-system kernel of everything downstream.
Treat the platform as a product with a real backlog. Roadmaps, release notes, internal customer interviews, public adoption metrics, deprecation policies, version-support guarantees. The discipline that distinguishes a product team from an infrastructure team is observable in the artefacts they maintain. If the platform team does not produce these, it is, definitionally, an infrastructure-tooling team — regardless of what is written on its slide.
What this means operationally
The narrative-versus-reality gap on platform engineering in Switzerland is wide and durable. The jump from stage one to stage two is largely a tooling and budget problem. The jump from stage two to stage three is not. It is a product-thinking and organisational-trust problem, and the CTOs who internalise that — and resist the pull to solve it with another CNCF-graduated tool — will ship faster, retain senior engineers longer, and accumulate less platform debt than the organisations buying their way through it.
A platform that internal developers do not use is not a platform. It is a sunk cost wearing a platform's name. The first measurement worth taking is whether the platform's internal users would choose to use it if a free alternative existed. The answer to that question, in most Swiss organisations, is more diagnostic than the entire architecture review.