Platform Engineering: When Growing Teams Need an Internal Developer Platform

Why developer friction reaches a breaking point

Platform engineering rarely enters the conversation as a strategy. It shows up as a symptom: every team handles its own continuous integration and continuous delivery (CI/CD) and waits days on an infrastructure ticket before it can set up environments and security scanning from scratch. None of this appears on a dashboard. It surfaces when a new hire takes two weeks to understand how a deploy actually works. It also appears when two services ship in incompatible ways. Your best engineers spend their afternoons on glue code instead of the product.

The research backs up what you feel. A 2026 Chainguard survey of 1,200 engineers found they spend just 16% of their week writing code and building features, despite 93% saying that's the part of the job they value most. Another report of engineering leaders put 30% of engineers' time into manual infrastructure work, including audits and tool maintenance.

For a CFO or CTO, that 16% translates into a velocity and retention problem stated in financial terms. If your average fully-loaded engineer costs $150K–$180K a year, spending 84% of the week on infrastructure friction instead of product work means you're paying full engineering salaries for a fraction of the output you hired for. At a 100-developer mid-market org, that gap can represent several million dollars a year in fully-loaded cost going toward non-product work. Developers stuck on glue code and ticket queues instead of the work they were hired to do are the ones most likely to leave, and replacing a mid-level engineer typically costs 50–200% of their salary once recruiting, ramp time, and lost productivity are counted.

This is the moment when "just hire more DevOps" stops working. Adding people to a ticket queue scales the queue while leaving the outcome unchanged. The sheer amount your developers must hold in their heads to ship anything at all becomes a bottleneck.

The hidden cost of platform engineering: Day 2 operations

Standing up a golden path or a service catalog is a project with a start and a finish. Keeping it alive is not. Kubernetes versions age out, CVEs land in base images, CI/CD tooling ships breaking changes, and every integration the platform depends on drifts out of sync on its own schedule. None of this is optional maintenance.

This is the cost mid-sized organizations chronically underestimate. The build is the visible line item. Day 2 operations (patching, upgrades, on-call, toolchain maintenance) is the recurring one, and it doesn't shrink once the platform ships. It's also exactly the work an MSP is built to absorb: while your product teams stay focused on internal developer research and golden-path design, the MSP owns the 24/7 reliability, security patching, and toolchain upgrades of the underlying layer.

What platform engineering actually is

Platform engineering is a product discipline that builds and maintains reusable internal capabilities for developers. It is not a renamed operations department, and it is not your existing DevOps team with a new sign on the door. The difference is where the work starts: the platform team researches its own engineers' needs. It ships capabilities and iterates based on adoption, as any product team does for customers.

Kaspar von Grünberg, founder and CEO of Humanitec, put the discipline this way: platform engineering is "the art of designing and binding" all the different tech and tools inside an organization into a golden path that enables self-service for developers and reduces cognitive load.

Three terms get confused constantly, and the confusion is expensive. Keep them straight:

• Platform engineering is the discipline of a team that builds internal capabilities as a product.

• The internal developer platform is the thing that discipline produces, the full system that provides tools and automation on underlying infrastructure.

• The portal is the front door developers see.

How does this apply to your system? DevOps is a set of cultural and delivery practices. Site Reliability Engineering (SRE) applies software engineering to operations and reliability. Platform engineering takes the learnings from both and packages them into a product with real internal users. Martin Fowler, Chief Scientist at Thoughtworks, captured the reason it matters: the "primary benefit of a platform" is to reduce the cognitive load on the teams building your product.

Core capabilities of an internal developer platform

Think of what follows as a pieces of capability map. The thread running through all of them is the same: reduce developer cognitive load through opinionated defaults instead of handing engineers raw infrastructure and wishing them luck.

Golden paths and developer self-service

A golden path is an opinionated, pre-configured workflow that lets a developer use a pre-configured workflow to provision a service and deploy it in an environment independently. This is developer self-service, the core promise of the whole discipline.

A golden path template bundles the things every service needs anyway. That means a working CI/CD pipeline with security scanning and observability configured from the first commit. The developer gets all of it without assembling it by hand.

The critical design choice is to make a golden path a road. Evan Bottcher's much-cited principle is that platforms "must be compelling to use," and cannot stand on a mandate alone. If the paved road is genuinely the easiest route, developers take it. This is the capability that attacks the friction from the opening most directly, because developer self-service is what removes the wait.

Service catalog and reusable templates

The service catalog is the discoverable inventory of what exists: every service, who owns it, and which templates are available. Without one, teams reinvent pipelines nobody knew already existed, and ownership decays into a stale spreadsheet. Backstage, the open-source portal Spotify open-sourced in 2020, grew popular precisely because its foundation is a service catalog that tracks components and ownership in one place.

The catalog's companion is reusable templates. Standardized service scaffolding and shared CI/CD templates create consistency across teams. This ties straight back to onboarding. A new engineer who follows the catalog's standard service-creation path understands your delivery model in an afternoon instead of a fortnight.

Infrastructure, Kubernetes and environments

This is the resource layer, where the platform uses infrastructure as code to abstract Kubernetes and cloud environments so a developer gets a working environment without opening a Terraform module or hand-editing a manifest. The platform team encodes the right way to do it once, and every team inherits that decision automatically.

Abstraction shifts complexity down into the platform, where specialists own it for all product teams. DORA describes this as the practice of "shift down" cognitive load, which moves the hard parts of Kubernetes and cloud networking into the platform so developers can stay focused on delivering value. The complexity still exists. It just stops being every engineer's problem.

Observability, security and guardrails

A good platform bakes observability and security controls, including monitoring, into the golden paths so visibility and compliance are the default. This is the direct answer to the scattered security controls in the opening. When scanning and monitoring ship inside the template, security stops being a step teams skip under deadline pressure.

Guardrails hold team autonomy and organizational standards in tension. The platform enforces security and reliability requirements, including cost controls, inside the paved road itself and lets developers move freely within those bounds.

One capability gets underinvested more than any other: documentation and support. A golden path nobody understands is a golden path nobody uses. The unglamorous work of writing clear docs and answering questions is what decides whether adoption happens at all.

Why ABS Technologies manages out-of-the-box

Rather than building each of the capabilities above from scratch, ABS Technologies' managed platform ships several of them pre-built:

• Pre-built Kubernetes blueprints for common workload patterns, so environments are provisioned against a hardened baseline instead of a blank cluster

• Automated CI/CD security gates built into the pipeline template, so scanning is enforced by default rather than left to each team's discipline

• Built-in cost controls at the infrastructure layer, so spend visibility doesn't depend on standing up a separate FinOps effort

• Ongoing Day 2 ownership as part of the managed service, not a one-time deliverable

Signals your team is ready

How do you know it is time? Gartner predicts that by 2026, 80% of large software engineering organizations will have platform teams, up from 45% in 2022. While the forecast is a reason to understand the discipline, it's not a reason to greenlight a team this quarter. Judge your own situation against concrete signals.

The clearest signal is where your ops or platform-adjacent team spends its time. If most of their week goes to reactive ticket work and repeated pipeline questions, while environment provisioning and access resets consume the rest, the demand for developer self-service already exists. You are paying for it manually.

The second signal is stability. Your delivery has to be reliable enough to build on. If deploys are unpredictable and production breaks in ways nobody can explain, a platform will only industrialize the chaos. Fix the foundation first. A platform standardizes what you do, so what you do needs to be worth standardizing.

The third is a simple onboarding test. Sit a new engineer in front of your deployment pipeline and see whether they can understand it within an hour. If they can't, the tacit knowledge in your senior engineers' heads is a tax on every hire you make. The scale of that tax is real. Team Topologies analysis illustrates that if 400 engineers are each blocked one hour a day, at a fully loaded cost of €160K over 260 working days, the waste runs to roughly €8 million a year.

When hiring an internal team is the wrong move (and an MSP is the right one).

A strategist who only ever sells you the biggest project isn't serving you. Plenty of teams that feel this pain don't need a dedicated internal platform engineering function. But "don't build a team" isn't the same as "do nothing." For organizations in the 50–300 developer range, the honest choice usually is internal team vs. MSP.

For a small engineering org with a handful of services, a few well-made reusable pipeline templates in a shared scaffolding repository, or a bought tool that handles environment provisioning, will remove most of the pain. Developer self-service at small scale can rely on three good templates and a README.

Once you're past that scale, a lightweight fix and a full internal build both stop being the right answer. This is the gap an MSP is built to close: the same golden paths, service catalog, and guardrails a dedicated internal team would build, delivered and operated by a team that already has the expertise, without you carrying the hiring, ramp-up, or Day 2 operations cost internally.

The reason to be careful about the internal build is cost structure. A real internal developer platform is a multi-month build and a permanent cost center after that, because a platform product needs ongoing ownership. The pain has to justify that standing commitment.

A useful gut check before you commit to any path:

1. Do the same infrastructure requests repeat often enough that automating them saves real, recurring hours?

2. Would targeted automation or an off-the-shelf tool solve 80% of the problem for a fraction of the cost?

3. Is the friction spread across enough teams that a shared solution beats each team fixing it locally?

4. Is the gap between "templates aren't enough" and "we can staff a 5-person platform team" where you actually are? If so, that's the MSP-sized problem.

If the honest answers point to a lightweight fix, take the lightweight fix. If they point to the middle ground, an MSP is usually the faster, cheaper route to the same outcome as a full internal build.

Anti-patterns that sink platform engineering

The failure modes here are well documented, and they repeat because the underlying mistake repeats. Learn to recognize them because you'll be overseeing this effort.

The first is the ivory tower platform. DORA calls the related trap "build it, and they will come," where a team builds on assumptions without user research and produces an elegant thing nobody adopts. Developers hit a tool that adds friction, and they route around it with workarounds and shadow IT, which defeats the standardization the platform was meant to deliver.

The second is treating the portal as if it were the platform. The portal is the front door. If you polish the interface while the capabilities behind it are thin, you get a pretty catalog of stale data. Spotify's own VP of Engineering noted that while Backstage adoption is high internally, it often stalls in other organizations, because the fundamentals underneath were never solved.

The third is mandate-driven adoption. Forcing teams onto the platform by decree produces resistance and resentment, which undermines use. The State of Platform Engineering report found that 36.6% of adoption remains mandate-driven, a sign many teams never escaped this trap. Adoption has to be earned through usefulness.

The fourth is underinvesting in the boring essentials: ownership and documentation. It also underinvests in support. The common thread across all four is the same failure. Someone skipped the developer research and forgot the platform is a product with users who get to decide whether it lives.

The fifth is the DIY trap. Teams sink 12 months building a custom internal developer portal from scratch. It leaves the team owning the maintenance of a bespoke portal indefinitely, on top of everything else on this list. Leveraging a proven framework gets the same capability in weeks instead of a year, without inheriting a second unmaintained system.

A minimum viable platform engineering rollout

Start small, because a thin but usable platform can ship in weeks while a full one takes many months. The State of Platform Engineering Report Vol. 4 found that 35.2% of teams deliver measurable value within the first six months, and the teams that do use an iterative minimum viable platform approach.

Lead with research. Shadow and interview your developers to identify the single highest-friction path they walk every day. Then build one excellent golden path for that path and nothing else yet. Ship it, then use adoption to determine whether that first path has earned its keep.

The build-versus-buy decision belongs here, and it comes down to a few honest questions:

• How mature is the team you'd put on this, and can they own a bought tool as readily as a built one?

• How genuinely unique are your requirements, or are they the same needs a commercial internal developer platform already covers?

• What is the true maintenance cost of building, carried for years, against the license cost of buying?

• Which route gets a working golden path in front of developers faster?

Whatever you decide, name a platform product owner from day one and treat the platform as a product. The State of Platform Engineering report is explicit that the most successful enterprises have a dedicated Platform Product Manager with full-time attention. Without an owner accountable for adoption and developer self-service, the effort drifts back into an internal tools project that quietly stalls.

Metrics that prove it worked

You'll need numbers to justify continued investment to your own leadership, and the good ones map straight back to the friction you started with. The DORA metrics are the industry standard, and platform engineering moves them. DORA's research found that elite teams deploy far more often than low performers while maintaining lower change failure rates, which broke the old assumption that speed and stability trade off against each other.

Track these outcome measures together:

• Deployment frequency and environment lead time

• Change failure rate

• Onboarding time

• Adoption rate and developer satisfaction

The telltale sign of a platform quietly failing is a healthy-looking catalog with a low adoption rate. If engineers are routing around the golden paths, the DORA numbers won't move no matter how polished the portal looks. Watch adoption and satisfaction as closely as delivery speed, because a platform nobody uses fails silently.

Deciding your next move on platform engineering

You now have enough to decide. Assess whether your delivery is stable enough to support a discovery effort. If your foundations are still shaky, defer and fix delivery first. And if the pain is real but small, solve it with targeted automation instead of a permanent team. Use the anti-patterns as a final gut check: start with research and earn adoption. Give the platform a real owner.

ABS Technologies runs platform discovery and builds cloud and DevOps guardrails beneath your internal developer platform, including security controls. Book a free platform engineering consultation with ABS to map your highest-friction path and a sensible first golden path.