The Quiet Rise of Platform Teams Inside Mid-Sized Software Companies

A pattern in the job postings

Look at engineering job postings from real estate and proptech software companies over the past few years and a pattern shows up. Companies with a handful of product squads start listing roles like "Platform Engineer," "Developer Experience Engineer," or "Internal Tools Lead." These aren't DevOps postings, and they aren't product engineering postings. They describe something in between: engineers whose customers are other engineers.

This shift tends to happen around the same size, roughly 30 to 60 engineers split across four or more feature teams. Below that threshold, most companies get by with a mix of individual contributors handling infrastructure part-time and a small ops or DevOps function keeping production upright. Above it, something starts to break, and it isn't reliability. It's duplication.

What proptech engineering orgs duplicate

Real estate and property management software has a specific shape. A mid-sized proptech company might have separate teams for listings and search, leasing workflows, tenant payments, maintenance ticketing, and integrations with MLS feeds, background check vendors, and e-signature providers. Each of these teams ships independently, and each one, left alone, tends to build its own version of the same scaffolding.

One team writes its own retry logic for a flaky third-party API. Another team, dealing with a different vendor but the same category of problem, writes its own retry logic too, slightly differently, with different failure modes. The leasing team builds a staging environment that mimics production. The payments team builds another one, because the leasing team's setup doesn't fit its compliance requirements. Every team ends up with its own CI pipeline, its own conventions for feature flags, its own approach to seeding test data that looks like a realistic multi-unit property portfolio.

None of this is anyone doing something wrong. It's what happens when smart engineers solve the problem in front of them without a shared foundation underneath them. Early on, when there are two or three teams, the duplication is a minor inefficiency. Once there are five or six, it becomes a tax that shows up in every sprint: onboarding a new engineer takes two weeks instead of two days because there's no standard way to spin up a local environment, deploys require tribal knowledge specific to each team, and a security patch that should take an afternoon takes a week because it has to be applied six different ways.

Why this isn't a DevOps problem

It's worth being precise about what a platform team is not. A traditional DevOps team focuses outward, toward production: uptime, incident response, infrastructure provisioning, monitoring. A platform team focuses inward, toward the other engineers in the company. Its job is to make the other feature teams faster and more consistent, through shared deployment pipelines, internal libraries, service templates, testing frameworks, and self-service tooling that removes the need for each team to reinvent basic infrastructure.

The Team Topologies framework, one of the more widely adopted organizational-design models in software engineering, draws this distinction explicitly, separating stream-aligned teams (product teams building customer-facing features), platform teams (providing internal services that reduce cognitive load for stream-aligned teams), and enabling teams (temporary specialists who help other teams adopt new practices). The framework's insight isn't that platform teams are more important than product teams. It's that mixing the two functions inside the same people or the same DevOps team creates a bottleneck, because production firefighting always wins against long-term tooling investment when the same team owns both.

That tradeoff is exactly what pushes companies to formally split the roles once they're big enough to feel the cost. A five-person DevOps team asked to both keep the lights on and build a shared deployment pipeline will always choose the pager over the roadmap. A dedicated platform team, with its own backlog and its own accountability for developer productivity, can actually ship the pipeline.

Industry survey data backs up how widespread this has become as a distinct discipline rather than a rebranding of ops work. Puppet's long-running research on DevOps and platform engineering practices has tracked the emergence of platform teams as a distinct organizational function, separate from both traditional operations and product engineering, across companies of meaningfully varied size and maturity.

The math that justifies the headcount

A platform team is a real cost. It's typically two to five engineers who aren't shipping customer-facing features, which is a hard sell to a founder or VP of Engineering watching a product roadmap slip. The way to justify it isn't a vague appeal to "developer experience." It's arithmetic.

If a company has five product teams and each one spends roughly a day a week, conservatively, dealing with infrastructure friction that a shared platform would eliminate, that's five person-days a week of lost product output, every week, indefinitely. A platform team of three engineers that eliminates even half of that friction pays for itself in raw output within a quarter, before counting the harder-to-measure costs: onboarding time, incident frequency from inconsistent deployment practices, and the opportunity cost of senior engineers building infrastructure instead of mentoring or shipping.

The proptech-specific version of this math often centers on compliance and integration variance. A company selling into different states or property types deals with different regulatory requirements, different MLS data formats, different vendor APIs for background checks or rent payments. Without a platform layer, each product team absorbs that variance independently, rebuilding the same compliance guardrails and integration handling five different ways. A platform team that builds one well-tested abstraction over that variance removes an entire category of duplicated risk, not just duplicated code.

Judging your own org

A few concrete signals suggest a company has crossed the threshold where a platform team pays for itself: more than three teams maintaining separate CI/CD configurations that do functionally the same thing, onboarding time for new engineers exceeding a week for reasons unrelated to domain complexity, incident postmortems that repeatedly trace back to inconsistent deployment or environment setup rather than product logic, and senior engineers on product teams spending meaningful time each sprint on infrastructure rather than features.

If none of those apply yet, a formal platform team is probably premature, and the money is better spent on product engineers or, as covered in promoting a tech lead instead of hiring one externally, on developing the kind of senior engineer who can absorb some of that infrastructure ownership part-time. If most of them do apply, the company isn't deciding whether to build shared infrastructure. It's deciding whether to keep paying for it five times over without noticing.