As Head of Platform Engineering at AutoScout24 and Trader Inc., I’ve been working with Platform Engineering practices for years. In that time, I’ve seen what happens when they are present — and what happens when they are not, especially during acquisitions. In this piece, I focus on the structural shifts I’m seeing, the trade-offs they introduce, and what I would prioritize if I were building or evolving a platform organization today.
Why Platform Engineering Is Now Mandatory
Platform Engineering has crossed a threshold. It is no longer something only elite tech companies do well. It has become a requirement for any organization operating modern software systems at scale. The reason is straightforward: system complexity has outpaced human coordination. Microservices, multi-cloud setups, regulatory constraints, and AI workloads don’t compose cleanly through local team decisions alone. Without a platform, organizations compensate with process, tickets, and heroics.
DevOps improved autonomy at the team level, but it never fully solved coordination at the organizational level. “You build it, you run it” only works when teams share well-designed primitives to build and run on. Without those, every team reinvents the same solutions, ownership becomes fragile, onboarding slows down, and operational risk accumulates quietly. In practice, the failure mode looks predictable: every new service requires nuanced CI, custom dashboards, manual IAM setup, and implicit ownership that only exists in someone’s head.
Platform Engineering institutionalizes DevOps. It does so by making the right way the default way, not through mandates, but through paved paths that encode what the organization has already learned. A useful mental model is simple. Product teams optimize for delivering features. Platform teams optimize for the system that enables delivery. The platform becomes the control plane for software delivery: abstracting infrastructure, encoding standards, and providing self-service that scales across dozens or hundreds of teams. In practical terms, this is where standards, automation, and ownership metadata live.
This distinction becomes especially visible during acquisitions. Teams that grew up without Platform Engineering often rely on tribal knowledge and manual processes. Onboarding them is rarely about tools first. It’s about aligning operating models. What consistently works is introducing the platform as the default delivery path, reinforcing ownership with clear guardrails, and focusing on enablement rather than enforcement.
At scale, this enablement becomes a capability of its own. Platform advocates or enablement teams help business units adopt the platform effectively and prevent local workarounds from eroding consistency over time. Organizations that delay this investment accumulate organizational debt. Delivery slows despite growing headcount. Incidents increase. Senior engineers become human glue. Cloud and compliance costs rise without clear ownership. By the time leadership reacts, the gap is structural.
Platform Engineering is not about centralization for its own sake. It is a deliberate trade-off: slightly less local freedom in exchange for much higher global throughput and reliability. Teams will still ship software without it — just slower, riskier, and at a higher human cost.
Internal Developer Platforms as Standard Infrastructure
At a certain scale, an Internal Developer Platform stops being optional. Once you operate dozens of teams, hundreds of services, and multiple cloud environments, you need a single system of record for how software is built, owned, operated, and governed.
High-performing platforms are not just deployment portals. They act as authoritative sources of truth for service ownership, lifecycle, environments, operational metadata, and compliance posture. When this data is reliable, it becomes reusable everywhere else: incident management, KPIs, cost attribution, and operational reviews.
At AutoScout24 & Trader, Backstage plays this role. Service ownership defined in the platform flows into incident reports, Core Tech KPIs, and KTLO attribution. That only works if the data stays clean and enforced. An IDP with stale metadata quickly becomes a liability. This pattern is not specific to Backstage. Any service catalog can work if ownership is enforced and reused downstream in incidents, reviews, and cost attribution.
Many organizations underestimate the difference between a portal and a platform. Standing up a UI is easy. Keeping the platform relevant over time is hard. Ownership fields decay, catalog entries go stale, paved paths lag reality, and exceptions quietly become the norm. Once trust erodes, developers stop treating the platform as a source of truth, and recovering that trust is expensive.
Early adopters often built heavily customized platforms. We did too, before moving to Backstage. The industry has become more pragmatic since then. Open-source frameworks provide extensibility, managed solutions reduce undifferentiated effort, and internal investment is focused where the platform encodes company-specific rules. The real question is no longer whether something can be built, but whether it helps developers ship better software faster.
A healthy platform is treated like production software. Ownership is enforced at creation time, unused entries are cleaned up, platform data feeds processes developers care about, and using the platform is always easier than bypassing it. When that balance is right, the platform becomes boring, trusted, and essential — exactly what you want.
Kubernetes as a Foundation, Not a Product
Kubernetes itself is no longer the hard part. It is mature and operationally stable in most organizations. What differentiates platforms now is how much of that complexity developers are exposed to.
Kubernetes should not be a developer-facing product. Exposing raw clusters, YAML, and Helm charts to every team increases cognitive load and inconsistency. The emerging pattern is clear: Kubernetes is the compute foundation, the platform is the interface. Developers express intent, the platform translates that intent into resources, policies, and workflows.
At AutoScout24, our paved-path compute is Kubernetes-based. We still support EC2 workloads with standardized AMIs, but Kubernetes is the default and continues to expand. The goal is not forced migration, but making the Kubernetes path clearly superior for most use cases.
GitOps has become the dominant control mechanism in this model. Tools like ArgoCD are foundational for managing desired state, drift detection, and environment promotion. They provide a single source of truth for desired state, automated and auditable deployments, and consistent promotion across environments. Humans own intent. The platform owns reconciliation.
The real leverage comes from layering opinionated workflows on top of Kubernetes: service templates, default security and observability, standardized deployment strategies, and GitOps-driven rollouts. Developers should rarely touch Kubernetes primitives directly. When they do, it should be a conscious exception.
Most organizations run mixed compute models, and that is fine. The mistake is treating them as peers in developer experience. Over time, teams naturally migrate toward the path with the least friction.
What differentiates platforms is not Kubernetes itself, but how invisible it becomes.
AI as a First-Class Platform User
AI has rapidly shifted from being just a productivity tool at the edges of development. It is becoming an active participant in the delivery system. That shift forces platforms to treat AI not as a feature, but as a user, with identity, permissions, limits, and accountability.
Early AI adoption was individual and ungoverned. That does not scale. Mature organizations are moving AI capabilities into the platform layer, where they can be governed, audited, integrated into workflows, and bounded by policy and cost controls.
Treating AI as a platform actor means it has explicit identities, scoped roles, quotas, and full observability. AI agents can validate configurations, trigger deployments, or remediate issues — but only within clear boundaries. Unbounded autonomy is operational risk. Platforms exist to contain that risk.
This becomes especially important because AI-generated code often passes syntactic checks while failing operational reality. Platforms increasingly act as safety nets through validation, policy enforcement, and runtime safeguards. Without that layer, AI adoption stalls after the first serious incident.
The next step is multi-agent systems: specialized agents for code generation, security validation, deployment, rollback, and runtime monitoring. Platform Engineering provides the orchestration layer that integrates these agents into CI/CD and GitOps workflows and ensures they act coherently.
A simple rule holds: AI belongs in the platform, not just in the IDE. Centralizing it early creates leverage. Retrofitting guardrails later is far more expensive.
Observability as a Platform Contract
Observability has become a crucial part of the platform contract. Every service created through the platform is observable by default.
High-maturity organizations treat observability as a managed platform capability. Logging, metrics, tracing, dashboards, and incident integration are standardized and inherited automatically through paved paths. This reduces variance and enables meaningful cross-service analysis.
OpenTelemetry has effectively become the baseline. Its value is practical: vendor neutrality, consistent semantics, and easier evolution of the observability stack over time.
As systems scale, manual observability does not. Platforms increasingly apply automation and AI to detect anomalies, correlate signals, surface likely root causes, and reduce alert fatigue. The goal is not to replace engineers, but to compress time to insight.
Cost is now inseparable from observability. Telemetry is expensive, and collecting everything is neither useful nor sustainable. Mature platforms enforce sampling, retention policies, telemetry budgets, and observability-as-code. The trade-off is intentional: enough signal to operate safely, not unlimited data.
From Automation to Self-Optimizing Systems
Automation has moved beyond scripts and runbooks. The focus is now on systems that adapt themselves without waiting for human intervention.
Basic self-healing is table stakes. Restarting containers, scaling replicas, and rolling back failed deployments are expected. The real shift is toward predictive and intent-based automation.
Instead of specifying how systems should behave, teams specify what they want: reliability targets, performance objectives, cost boundaries. The platform translates intent into action and continuously adjusts within defined guardrails.
AIOps works only when it is deeply integrated with telemetry, deployment context, and policy. In that setup, platforms can forecast demand, detect anomalies, trigger remediation, and optimize cost and performance in real time.
Autonomy requires boundaries. Clear blast-radius limits, policy-defined ceilings, human approval for structural changes, and full audit trails are non-negotiable. The trade-off is clear: more autonomy yields lower toil and faster response, but only if constraints are enforced rigorously.
Platforms should own routine recovery, optimization, and tuning. Humans should own objectives, policy, and system design.
Security, Compliance, and FinOps by Default
Security and compliance have shifted from process to platform defaults. If a deployment violates policy, it simply does not happen. Manual reviews cannot keep up with continuous delivery and AI-generated changes.
Policy-as-code has become the enforcement layer. Encryption, IAM, network rules, approved dependencies, compliance constraints, and cost limits are encoded, versioned, tested, and enforced automatically. Developers learn constraints through fast feedback, not audits.
AI changes the threat model further. Platforms must control AI access to data, validate AI-generated artifacts, prevent privilege escalation, and track provenance end to end. Supply chain security, SBOMs, and artifact signing are now baseline expectations.
FinOps follows the same pattern. Cost management has moved into engineering workflows. Platforms surface cost at creation time, enforce budgets automatically, and tie spend to service ownership. This is especially critical for AI workloads, where cost spikes can appear within hours.
The goal is not to turn engineers into accountants. It is to make cost-aware decisions the default path.
Platform as a Product, Teams as Enablers
Platform Engineering only works when the platform is treated as a product. Developers are the customers. Adoption is earned, not mandated.
This requires product discipline: a roadmap, explicit priorities, non-goals, documentation, onboarding, and continuous feedback. It also requires measurement. Time to first production deployment, deployment frequency, failure rates, developer satisfaction, and toil reduction all matter. Platforms that do not measure outcomes struggle to justify investment or improve intentionally.
As scope grows, ownership must become explicit. Platform Product Managers, Developer Experience Leads, and specialized platform engineers are no longer optional roles. They reflect the reality that prioritization and trade-offs matter.
High-maturity platforms reduce tool sprawl through product decisions. Fewer supported tools, opinionated defaults, and clear exception paths reduce cognitive load and long-term maintenance costs, even if they limit short-term freedom.
Platform teams succeed when they are small, senior, and embedded. They enable product teams rather than replacing them. They collaborate early, observe real usage, and evolve abstractions based on friction, not theory.
Closing Thoughts
Platform Engineering is not about control. It is about leverage.
Organizations that succeed accept a small reduction in local freedom to gain a large increase in global throughput, safety, and sustainability. That trade-off is uncomfortable, but unavoidable.
The platforms that win are boring, trusted, and widely adopted. The ones that fail are optional, fragmented, and under-owned. If I were starting or course-correcting today, I would focus on four things first:
- a reliable service catalog with enforced ownership
- one strong paved path on a primary compute target
- policy and cost gates integrated into delivery
- a small set of outcome metrics tracked consistently
The direction of travel is clear. What remains is how deliberately leaders choose to move.