The platform engineering wave has finally crested. Gartner’s prediction that 80% of large engineering organisations would form dedicated platform teams by 2026 is playing out in real time — and at the centre of every mature platform sits an Internal Developer Portal (IDP).
But here’s the uncomfortable truth: most teams adopting IDPs are doing so because they feel they should, not because they’ve identified a clear problem worth solving. The result? Expensive shelfware that developers ignore in favour of Slack messages and tribal knowledge.
Let’s cut through the noise and examine when an IDP genuinely earns its keep — and how to choose between Backstage, Port, Cortex, and the growing field of managed alternatives.
TL;DR
- Internal Developer Portals centralise service catalogues, documentation, and self-service workflows — but only deliver value if you have genuine discoverability or onboarding pain
- Backstage (open-source, CNCF) holds ~89% market share but demands 2-4 months of setup and ongoing plugin maintenance — treat it as a product, not a side project
- Managed alternatives like Port, Cortex, and OpsLevel trade customisation for time-to-value, often delivering results in days rather than months
- The real decision isn’t “which portal” — it’s whether your team has outgrown wikis, runbooks, and Slack threads as the system of record for service ownership
- Start with a service catalogue before layering on self-service scaffolding, scorecards, and workflow automation
What an Internal Developer Portal Actually Does
Strip away the marketing and an IDP serves three core functions:
1. Service Catalogue — a single source of truth for every service, library, and infrastructure component your organisation owns. Who built it, who maintains it, what depends on it, where the docs live.
2. Self-Service Workflows — templated actions that let developers spin up new services, provision databases, request access, or trigger deployments without filing tickets or pinging someone on Slack.
3. Standards Enforcement — scorecards and checks that measure whether services meet your organisation’s production-readiness criteria (monitoring configured, runbooks documented, security scanning enabled).
When these three capabilities work together, you eliminate the “who owns this?” question, reduce onboarding time from weeks to days, and create a feedback loop that nudges teams toward best practices without top-down mandates.
The Honest “Do You Need One?” Checklist
Before evaluating tools, answer these questions honestly:
- Do developers regularly spend time finding out who owns a service? If your answer is “we just ask in Slack”, that works at 20 people. At 50+, it becomes a tax on everyone’s time.
- Does onboarding a new engineer take more than a week? If institutional knowledge lives in people’s heads rather than in discoverable systems, you have a portal-shaped problem.
- Are you running more than 30 services? Below this threshold, a well-maintained wiki or Notion database often suffices. Above it, the combinatorial complexity of ownership, dependencies, and standards makes manual tracking untenable.
- Do teams regularly reinvent solutions that already exist internally? Duplicate libraries, overlapping services, and “I didn’t know we had that” conversations indicate a discoverability gap.
If you answered yes to two or more, read on. If not, save yourself the investment — a shared spreadsheet and clear documentation conventions will serve you better than a portal nobody uses.
Backstage: The Open-Source Heavyweight
Spotify’s Backstage, now a CNCF incubating project, dominates the IDP landscape with roughly 89% adoption among organisations that have committed to a portal. Its plugin ecosystem is vast, its community active, and its flexibility unmatched.
But flexibility comes at a cost. Backstage is a framework, not a product. You’ll need:
- 2-4 months to reach a useful state (catalogue populated, key plugins configured, authentication integrated)
- A dedicated team (or at minimum, a dedicated engineer) treating the portal as an internal product — triaging feature requests, updating plugins, ensuring adoption
- React/TypeScript expertise for custom plugin development
- Ongoing maintenance — plugin compatibility breaks on upgrades, and the ecosystem moves fast
Backstage makes sense when you have the engineering capacity to invest in it long-term, need deep customisation, or have compliance requirements that demand self-hosted solutions.
Managed Alternatives: Port, Cortex, and OpsLevel
If Backstage is the Linux of IDPs, the managed alternatives are macOS — less configurable, but dramatically faster to productive use.
Port stands out for its blueprint-based data model. You define entity types and relationships through a no-code interface, effectively modelling your entire engineering organisation without writing YAML files. It’s particularly strong for teams that need flexibility without Backstage’s maintenance burden.
Cortex leads in the enterprise space with pre-built scorecards, automated service maturity tracking, and executive-facing dashboards. If your primary goal is driving production-readiness standards across a large organisation, Cortex gets you there fastest.
OpsLevel occupies the middle ground — a managed catalogue with AI-powered automatic service detection and strong integrations. Its checks-as-code approach appeals to teams that want standards enforcement without manual configuration.
The trade-off across all managed options: you’re paying a per-service or per-user fee (typically £8-25/user/month) and accepting the vendor’s opinion about how portals should work. For most teams under 200 engineers, this is the rational choice — the total cost of ownership is lower than self-hosting Backstage when you factor in engineering time.
The Implementation Playbook
Regardless of which tool you choose, the implementation pattern that consistently works follows a crawl-walk-run approach:
Week 1-2: Service Catalogue — import your services from existing sources (GitHub repos, Kubernetes namespaces, Terraform state). Assign ownership. This alone delivers immediate value because you’ve created a searchable, linkable record of “what exists and who owns it”.
Week 3-4: Documentation Links — connect existing docs, runbooks, and architecture decision records to their respective services. Don’t create new documentation yet — just make existing knowledge findable.
Month 2: Scorecards — define 3-5 production-readiness criteria (has monitoring? has runbook? security scan enabled?). Publish scores transparently. Teams will self-correct without mandates.
Month 3+: Self-Service Templates — build golden paths for common operations (new service creation, database provisioning, environment setup). Each template you add removes a class of tickets from your platform team’s queue.
The critical mistake teams make is starting with self-service workflows before the catalogue is populated. Developers won’t use scaffolding templates from a portal they never visit. Build the habit of going to the portal first (for ownership lookups, docs, scores), then layer on workflows once traffic is established.
What This Means for Growing Teams
If you’re a team of 10-30 engineers and feeling the first pangs of “I don’t know who owns what”, you’re at the inflection point. You don’t need a full IDP yet, but you need the foundations — a service registry, clear ownership, documented standards.
Start lightweight. A structured YAML file in your monorepo, a shared Notion database, or even a well-maintained README with a service table. When the pain of maintaining that manually exceeds the cost of adopting tooling, you’ll know it’s time.
For teams already past that threshold — dealing with 50+ services, multi-team coordination, and frequent “who owns this?” interruptions — the ROI of a proper IDP is measurable in weeks, not months. The platform engineering investment pays for itself in reduced cognitive load, faster onboarding, and fewer production incidents caused by “nobody knew this service existed”.
Where REPTILEHAUS Fits
We’ve helped several clients navigate this exact decision — from early-stage startups deciding whether Backstage is overkill, to scale-ups migrating from wiki-based service registries to managed IDPs. Our DevOps and platform engineering team specialises in setting up the integrations that make portals actually useful: CI/CD pipeline visibility, infrastructure-as-code scaffolding, and the GitHub/GitLab hooks that keep catalogues automatically in sync.
If you’re weighing the build-vs-buy decision for your platform engineering tooling, get in touch — we’ll give you an honest assessment of whether you need a portal at all.
📷 Photo by Luke Chesser on Unsplash
