When does a software company need a platform engineer, but not yet a platform team?

You probably already have a platform function

Platform work is much broader than managing Kubernetes. It includes cloud accounts and subscriptions, networking, identity and access, Infrastructure as Code, pipelines, deployments, secrets, DNS and certificates, databases and storage, observability, backups, environments, incidents and upgrades. When developers do this structurally, they collectively perform a platform function even if nobody calls it that.

The difference from a deliberate platform function is usually organisational rather than technical. There is no clear owner or reserved time. Standards differ by application, knowledge lives in people’s heads and operational work competes directly with product development. Improvements to backups, access or pipelines wait until an incident makes them urgent.

The development team has quietly become the platform team, only without the time, focus and explicit responsibility. That works for a while, especially while one experienced developer still understands every connection. As the company grows, this informal structure becomes increasingly expensive to maintain.

Seven signs it is no longer a side issue

1. Only one or two people understand how the complete environment fits together. They know which DNS record is exceptional, why a database restore is manual and which pipeline needs a special sequence. Their absence becomes an operational risk and every question lands with the same people.

2. New environments are copied and then adjusted manually. Copying feels fast, but every copy develops differences in network rules, secrets, sizing and monitoring. Soon nobody knows which environment represents the intended standard and recovery is difficult to test.

3. Terraform exists, but covers only part of the infrastructure or every project uses it differently. Infrastructure as Code is present without providing a reproducible baseline. Resources created outside code, inconsistent state handling and competing module patterns make routine changes needlessly risky.

4. Applications and teams have different deployment routes and operational agreements. One service uses a pipeline, another a script and a third needs manual steps. Releasing now requires knowledge of exceptions, and new developers mostly learn which route not to take.

5. Production access is permanent, too broad or hard to reconstruct. Nobody can quickly explain who has access, why it is needed and what actions were performed. This is not only an audit concern; it makes safe incident response and daily operations harder.

6. Developers repeatedly lose time to the same infrastructure, deployment and environment issues. A certificate expires, a pipeline fails at the same step or a test environment drifts again. Individually these look small; together they create recurring interruptions and context switching.

7. A larger customer, audit, incident or growth phase suddenly exposes the fragility. Requirements for recovery, logging, access or environment separation cannot be fixed with one setting. The external event did not create the platform problem; it revealed what was already informal and vulnerable.

Why “we are still too small” is partly correct

Not every software company needs several full-time platform engineers. A straightforward application with few deployments and one simple cloud environment can run perfectly well without a separate platform team. An internal developer platform, Kubernetes, a comprehensive self-service portal, dozens of golden paths and enterprise governance would mainly add maintenance.

Taking platform engineering seriously does not automatically mean hiring a team or building a heavy platform. It means deliberately choosing what to standardise, who owns it, what should be automated and how security, recovery and operations are organised. Sometimes a simple pipeline with well-managed Terraform is exactly enough.

The useful question is not how much platform technology you can add, but how much platform responsibility the organisation already carries. A company with eight engineers, multiple customer environments and strict access requirements may have more structural platform work than a larger team operating one predictable application.

• No Kubernetes without a suitable workload and operating capacity
• No self-service product for actions that rarely occur
• Do organise explicit ownership, reproducibility and recovery

What an external platform engineer can add

An external platform engineer is not merely additional delivery capacity. The main value can be temporary focus and ownership: inventorying the current situation, exposing dependencies and risks, and determining what can remain. This avoids replacing everything out of frustration when a targeted improvement would be enough.

The work can then become concrete: improve existing Terraform, standardise the cloud structure, establish a reliable delivery path, organise access and secrets, and strengthen observability, backups and recovery. Provisioning can be automated while documentation and runbooks explain normal use and incident handling.

The aim is not to keep all knowledge outside the organisation. Ownership is agreed with the internal team, decisions become transferable and developers learn to use the platform safely. Afterwards it should be clear what the team owns, what can wait and which components need structural support.

• Assess and prioritise before rebuilding
• Implement standards and automation where they remove repetition
• Transfer knowledge, runbooks and ownership to the internal team

Four starting points, one underlying problem

An organically grown AWS or Azure estate often starts with loose resources, partial Terraform and different decisions per project. A new product lacks a platform baseline entirely, so the challenge is to start solidly without designing for imaginary scale.

A VM-based estate demands increasing manual care; containerisation may be a next step, but need not be the first. Elsewhere applications are already containerised but run on one server, Docker Compose or custom scripts. Deployment, recovery and operations are then often not yet organised as a platform.

These situations require different technical answers. The underlying problem is the same when infrastructure slows the team, is insufficiently reproducible or depends too heavily on a few people. A sound approach therefore starts with the situation, not a predetermined product.

Platform engineering is not the same as Kubernetes

A good platform engineer does not start by asking, “Where shall we put the cluster?” First establish what slows the development team, which components create risk, which workloads exist and how often environments are created. Actual availability needs, knowledge and operating capacity also shape the answer.

The outcome may be better Terraform, standardised CI/CD, professional access and secret handling, or more automated VM operations. A managed container service, phased containerisation, EKS or AKS may fit. Sometimes better observability and clear support arrangements create most of the needed stability.

Quality lies in matching the solution to the problem. Replacing everything does not automatically make a fragile platform mature. Improving what works, reducing exceptions and making daily operations predictable often creates a reliable baseline faster.

• What is actually slowing developers today?
• What can safely stay and what creates structural risk?
• Which solution can the team operate after handover?

The tipping point: when platform work becomes structural

A practical rule of thumb: when several developers lose time every week to the same infrastructure, deployment or environment problems, platform engineering is probably no longer a luxury. Not every incident requires a new platform, but repetition shows that the underlying way of working no longer scales.

It becomes structural when problems recur, improvements are repeatedly postponed and concentrated knowledge creates risk. Product work slows, new hires or projects struggle to connect, and security and operations are repaired afterwards. At that point, pushing through once more is not neutral; it preserves the friction.

The right next step can still be small. A short discovery, one owner for the key platform decisions and a focused improvement backlog may be sufficient. The tipping point calls for deliberate ownership, not automatically a new organisational chart.