You probably don’t need an internal developer platform yet. If you have fewer than about four product teams, a good README and one paved CI template will beat a platform nobody has time to maintain. That’s the honest verdict most vendors won’t lead with. Platform engineering, the discipline of building an internal developer platform (IDP) so developers can self-serve infrastructure instead of filing tickets, pays off at scale. Gartner expects 80% of large software engineering organizations to run platform teams by 2026, up from 45% in 2022. At five engineers, it’s overhead.
We’re gmware, a custom software development firm in Austin, TX with engineering centers in Bangalore and Mohali, India, and we build and run platforms for companies past the point where ticket-ops stops scaling. This post covers what an IDP actually is, the problem it solves, the team size where it earns its keep, and the build-versus-buy call: Backstage, Port, Humanitec, or nothing yet.
What is an internal developer platform, in plain terms
An internal developer platform is the self-service layer between your developers and your infrastructure. Instead of a developer opening a ticket to get a new service, a database, and a deploy pipeline, then waiting two days for ops, they click a button in a portal and get all three in minutes, pre-wired to your standards.
The jargon around this is thick, so here’s the plain version. A “golden path” or “paved road” is the blessed, well-lit way to do a common task: spin up a service, add a queue, ship to staging. It’s paved because someone smoothed it out, and golden because it’s the path you actually want people on. The IDP is what serves those paths. Backstage, Spotify’s open-source framework, calls its core piece a software catalog: a single place that lists every service, who owns it, where its docs live, and how to deploy it.
The problem it attacks has a name too: cognitive load. A modern service touches Kubernetes, Terraform, CI, secrets, observability, and half a dozen cloud APIs. No single developer holds all of that in their head. Platform engineering emerged specifically to reduce that cognitive load by hiding the machinery behind self-service. Fewer decisions per developer, fewer tickets to the ops queue, faster path from idea to production.
Platform teams, 2022 to 2026 (Gartner)
An IDP kills the ticket-ops bottleneck
The ticket-ops bottleneck is the whole problem. Picture a mid-size engineering org with six product teams and one central ops team. Every new service, every database, every environment, every access grant routes through that one queue. Developers wait. Ops burns out doing repetitive provisioning. Nobody’s doing their best work.
An IDP turns that queue into a menu. The ops team’s expertise gets encoded once, into a golden path, and then every developer serves themselves against it. Ops stops being a ticket desk and starts being a product team whose product is the platform. That’s the actual pitch, and when it works, it’s a real change in how the org moves.
Does it work? The evidence is positive but honest. Google’s 2024 DORA report found internal developer platforms raised individual and team productivity by about 5%, with a 6% team-level gain from dedicated platform teams. Not a moonshot. A steady, compounding gain. DORA also flagged a trap worth knowing: platforms can temporarily dent throughput and change stability before they pay off, a J-curve where things dip before they climb. That dip is where a lot of underpowered platform efforts get killed.
Here’s an opinion we’ll defend: the productivity number is not the reason to build one. The reason is developer independence. When a developer can get what they need without waiting on a human, the whole system speeds up in ways a 5% average hides. The waiting was never on the dashboard.
When is an IDP worth it, by team size
This is the question that actually decides your spend, and most content dodges it. So here’s a straight table.
| Your situation | What you need | Skip the IDP? |
|---|---|---|
| 1 to 3 teams, one ops person | A README, a paved CI template, IaC modules | Yes. An IDP is premature. |
| 4 to 8 teams, ticket queue backing up | A lightweight portal (Port free tier or Backstage) | Maybe. Start with a catalog and one golden path. |
| 8+ teams, ops is a bottleneck | A real IDP with a dedicated platform team | Yes, build or buy one. |
| 15+ teams, multi-cloud, compliance | Platform team + orchestration (Humanitec-style) | Build it properly, staff it properly. |
The line we draw, and we’ll own it: under about four product teams, an IDP is premature. At that size, a well-written README, a single golden-path CI/CD template, and a small set of reusable infrastructure modules give you 80% of the benefit for 5% of the cost. A platform is software. It needs owners, a roadmap, on-call, and maintenance. If you can’t staff a platform team, you’re not building a platform. You’re building a side project that rots.
DORA’s own data backs the size cutoff: internal developer platforms show up far more in larger organizations, because that’s where the complexity that justifies them lives. A five-person team doesn’t have a cognitive-load problem worth a platform. It has a “write it down” problem.
IDP readiness by team count
Build with Backstage, buy Port or Humanitec, or wait
Three real options, plus the fourth nobody sells you: not yet.
Build with Backstage. Backstage is the open-source framework Spotify created and donated to the CNCF, where it’s an incubating project used to build developer portals. It’s free, endlessly extensible, and the de facto standard. It’s also a full software project you own: plugins to write, upgrades to chase, a portal to run. Teams underestimate this constantly. Backstage is a framework, not a product. You’re not installing a portal; you’re building one.
Buy Port. Port is a hosted internal developer portal you configure instead of code. Its pricing starts with a free tier for up to 15 seats, then $30 per seat per month for Basic and $40 for Standard. You trade Backstage’s infinite flexibility for time-to-value: a catalog and self-service actions in days, not a quarter. For most mid-market teams that don’t want to run a platform-engineering product internally, this is the sane default.
Buy Humanitec. Humanitec is a platform orchestrator, aimed at the deeper end: dynamic environment provisioning, configuration management, the actual “click a button, get real infrastructure” machinery underneath a portal. It sells tiered plans for small, growing, and large teams, with the enterprise tier carrying SOC 2, self-hosting, and compliance features. You reach for this when the hard part isn’t the catalog, it’s the provisioning.
Wait. If you’re under four teams, none of the above. Write the README. Ship the CI template. Come back when the ticket queue actually hurts.
| Option | Best for | Cost shape | The catch |
|---|---|---|---|
| Backstage (build) | 8+ teams, engineers to spare | Free software, high staffing | It’s a framework you build and run |
| Port (buy) | Mid-market wanting a portal fast | Free to ~$40/seat/mo | Less deep provisioning than an orchestrator |
| Humanitec (buy) | Complex, multi-cloud provisioning | Tiered, sales-led | Overkill if you just need a catalog |
| Nothing yet | Under 4 teams | Near zero | Requires the discipline to write things down |
Build, buy, or wait
When buying beats building Backstage
When you don’t have a platform team, buy. This is the verdict most engineering leaders need and rarely hear stated plainly. Backstage is genuinely excellent and genuinely free, and it will happily consume one to two full-time engineers indefinitely between plugin work, upgrades, and portal maintenance. If those engineers would otherwise be shipping your product, a hosted portal like Port is cheaper than it looks, even at $40 a seat, because the real cost of Backstage was never the license. It was the payroll.
Build Backstage when you have the scale to justify a standing platform team and requirements too specific for an off-the-shelf portal. Everyone else: buy, or wait. We’ve watched more than one team spend a quarter standing up Backstage, then realize they’d have been done in a week with a hosted tool and a smaller ambition. The framework wasn’t wrong. The timing was.
How gmware helps you decide, then build
We do the build-versus-buy call before we quote, because the answer changes the quote. If you’re under four teams, we’ll tell you to hold off and hand you the README template and the CI golden path instead of an invoice. Pointing a platform at an org that doesn’t have the load to justify one just adds a system to maintain.
When an IDP does make sense, our DevOps and cloud infrastructure practice scopes it honestly: Backstage if you’ve got the team and the specificity, a hosted portal if you don’t, and the golden paths and IaC modules underneath either. Delivery runs from Austin with engineering in Bangalore and Mohali, which keeps senior oversight on US hours without US-only burn rates. If the platform is one piece of a larger re-architecture, we fold it into a broader digital transformation plan rather than shipping a portal in a vacuum. For the cost side of the DevOps picture, our guide to DevOps consulting and cloud cost optimization covers where the spend actually goes, and if Kubernetes is the layer you’re wrestling with, managed Kubernetes services breaks down run-versus-outsource.
Tell us how many product teams you have and where the ticket queue hurts, and we’ll give you a straight answer on whether a platform is worth building, and if so, build-or-buy included, within 48 hours.