Most conversations I have about my work start with a small misunderstanding. I say I led an application platform organization, and the other person hears “platform” and pictures Kubernetes clusters, CI/CD pipelines, cloud provisioning, and on-call rotations for the infrastructure everything runs on. Reasonable guess. It’s just not what I do.
Over the last several years “platform engineering” has quietly narrowed to mean infrastructure platform: the DevOps and SRE-adjacent discipline of building the internal plumbing that other engineers deploy onto. That work is real and it matters. But the collapse of “platform” into “infrastructure platform” hides a second kind of platform work that sits much closer to the product, and conflating the two leads to bad org design and worse hiring decisions. This is the distinction I find myself explaining most often, so I want to lay it out properly.
What people mean by “platform” now
When a job posting or a conference talk says platform engineering today, it usually means some version of this: internal developer platforms, Kubernetes and container orchestration, CI/CD tooling, cloud infrastructure provisioning, observability stacks, and the reliability engineering that keeps all of it up. The customer of this work is other engineers. The job is to make it fast, safe, and boring to ship and run software. Golden paths, paved roads, self-service infrastructure.
This is the domain of DevOps and SRE, and it has largely annexed the word “platform.” If you go looking for platform-engineering content, the overwhelming majority of it is about this layer, and the major conferences that put “platform” in their tracks are mostly talking about it.
None of that is a complaint. It’s good work and it’s genuinely a platform. The problem is only that it has become the default and often the entire meaning of the term, which leaves the other kind of platform work without a clear name.
What application platform actually is
Application platform is the backend foundation the product itself is built on. Not the infrastructure the product runs on, but the shared services, data model, and core systems that every product feature depends on to function.
Concretely, at a SaaS company, application platform tends to own things like the core deployment and runtime that customer workloads execute in, the data pipeline that turns raw product output into the things customers actually see, the primary and per-tenant database architecture underneath every feature, the entitlements and licensing layer that decides what each customer is allowed to do, and the integrations and public APIs that connect the product to the rest of a customer’s world. The customer of this work is partly other product teams and partly, at one remove, the end user and the business itself.
That last part is the real distinction. Infrastructure platform is defined by the layer of the stack it operates at: below the application, keeping it running. Application platform is defined by its relationship to the product: it is the part of the application that many features share, built once so that product teams don’t each reinvent it. One is horizontal under everything. The other is foundational within the product.
The line isn’t always crisp, and healthy organizations have the two working closely together. But they are different jobs with different customers, different success metrics, and different centers of gravity. Infrastructure platform is measured on reliability, cost, and developer velocity. Application platform is measured on those too, but also on things like whether the business can ship a new pricing package without an engineering project, whether customer data is properly separated, and whether the product can support an enterprise deal’s requirements.
A concrete example: two platform teams, two jobs
The cleanest way I can show the difference is to describe how it played out in an organization I ran.
We had two platform teams that people outside engineering constantly confused with each other. One owned the ephemeral infrastructure: provisioning cloud environments on demand for each customer operation, tearing them down afterward, managing the fleet and the cloud spend and the scaling behavior. That is infrastructure platform work in its purest form. The customer is the system, the metrics are reliability and cost, and the questions are about capacity and provisioning.
The team I led owned the layer above that: the core runtime the customer’s workload actually executed inside, the ETL pipeline that processed the results into product data, the per-tenant database architecture, the licensing and entitlements system that governed what each customer could access, and the integrations connecting the product to customers’ other tools. Same word on the org chart, “platform,” but a different job. My teams’ work showed up directly in what the customer experienced and in what the business could sell. When the company wanted to launch a new packaging tier or close an enterprise deal that hinged on data separation or on a specific integration, that landed on the application platform side, not the infrastructure side.
The two were coupled, and at one point I merged a slice of the infrastructure team with the runtime team precisely because the ephemeral environment and the workload running inside it were one vertical system in practice, split across two reporting lines for historical reasons. That merge was an org-design decision that only made sense once you saw clearly which parts were infrastructure platform and which were application platform, and where the seam between them actually was. If you think of both simply as “platform,” you can’t reason about that seam at all.
Why the distinction matters for org design
The reason I care about naming this isn’t pedantry. It’s that the two kinds of platform work want to be organized differently, and treating them as one thing produces predictable failures.
Application platform teams need to sit close to product and to the business, because their roadmap is driven by product and business priorities as much as by technical health. The entitlements and licensing work I described wasn’t an infrastructure project; it was a response to the business needing to launch packages without a quarter of engineering work each time. Deciding to build that, and deciding whether to build the underlying integration layer ourselves or buy it from a vendor, were product and strategy calls made jointly with product leadership. An application platform org that’s structured and incentivized like an infrastructure org, kept at arm’s length from product and measured only on uptime and velocity, will consistently underinvest in exactly the work that makes it valuable.
Infrastructure platform teams, by contrast, are usually better off with a degree of separation from any single product area, because they serve all of them and need to make decisions that are globally right rather than locally convenient. Organize them too close to one product and they’ll optimize for that product’s needs at the expense of the rest.
Get the two confused and you get org structures where the wrong team owns the wrong decisions: infrastructure engineers pulled into product packaging debates they have no context for, or product-adjacent platform engineers held to reliability-only metrics that ignore the business capability they’re supposed to be building. Naming which kind of platform you have is the first step to organizing it correctly.
Why the distinction matters for hiring
The same confusion shows up in hiring, in both directions.
When I’m evaluated by people who read “platform” as infrastructure, they screen me against a mental model of an SRE or DevOps leader and wonder why my background is light on, say, running a Kubernetes platform team as its own product. It isn’t the job I did. My work was backend and application platform: data pipelines, multi-tenant data architecture, entitlements, integrations, the runtime the product executes in. Deep in backend systems and in the product, adjacent to but distinct from the infrastructure layer.
It runs the other way too. A team that actually needs application platform leadership, someone who can own the data model, the multi-tenancy strategy, the build-versus-buy call on an integration platform, and the partnership with product on all of it, will sometimes write the role as generic “platform engineering” and interview candidates whose entire experience is infrastructure and reliability. Those candidates are strong at a real thing, but it isn’t the thing the role needs, and neither side figures that out until late.
The fix is unglamorous: say which one you mean. If a role is about internal developer platforms, Kubernetes, and reliability, call it infrastructure platform or platform reliability and hire for that. If it’s about the backend foundation of the product, the data and tenancy and entitlements and integrations that product teams build on, call it application platform and hire for that. The skills overlap in the backend fundamentals and diverge sharply in where the work points: at the infrastructure, or at the product and the business.
Both are platform engineering. They are not the same job, and the word alone won’t tell you which one you’re looking at. That’s the whole point of insisting on the distinction: the moment you name it, the org-design and hiring decisions that were quietly going wrong start going right.