The build vs buy internal developer platform decision is rarely a choice between writing everything and purchasing everything. A platform combines interfaces, workflows, catalog data, orchestration, policy, documentation, support, and the underlying capabilities that actually build and run software. A commercial product can reduce implementation work while leaving integration and product ownership with the customer. An open framework can accelerate a portal while leaving operations and upgrades entirely local.
Feature grids obscure the durable question: who carries each obligation after launch, with what skills, response time, and exit path? CNCF describes platforms as integrated capabilities presented around internal user needs, and DORA emphasizes treating the platform as a product. Neither responsibility can be procured away. The evaluation should compare total operating burden for a bounded platform scope under realistic growth, incident, upgrade, and migration scenarios.
Define the platform scope before comparing products
List the user journeys the decision must support: discover an owned service, create a repository, request a database, deploy a release, inspect health, rotate a secret, or retire a workload. For each journey, name the systems involved, policy decisions, data sources, service-level need, and current cost. Decide whether the candidate is a portal, an orchestration layer, a control plane, a workflow product, or a broader suite. Products with the same market label may own very different layers.
Separate commodity capabilities from organization-specific contracts. Authentication, forms, catalog search, workflow execution, and plugin frameworks may be reusable. Your ownership model, account topology, network controls, approved resource classes, cost allocation, deployment checks, and exception process often are not. The more differentiation lives in local policy and integration, the less a nominally complete purchase removes. Conversely, building a polished commodity interface can consume scarce engineering capacity without creating unique value.
| Layer | Examples | Burden to price | Frequent oversight |
|---|---|---|---|
| Experience | Portal, CLI, API, docs, feedback | Design, accessibility, analytics, content | Buying UI does not create coherent journeys |
| Catalog | Entities, ownership, relations, discovery | Data governance, reconciliation, stewardship | License assumes metadata already exists |
| Orchestration | Templates, workflows, approvals | Actions, retries, state, idempotency | Happy-path demo omits partial failure |
| Capabilities | Clusters, databases, CI, identity | Integration, SLOs, capacity, lifecycle | Portal is mistaken for the platform |
| Governance | Policy, audit, permissions, exceptions | Rule ownership, evidence, review | Default roles do not match local authority |
| Operations | Upgrades, support, incidents, recovery | On-call, testing, observability, vendor escalation | Launch project excludes steady-state labor |
Map obligations, not just components
Create a responsibility matrix for product discovery, roadmap, UX, integration code, extension security, data quality, availability, backups, disaster recovery, upgrades, vulnerability response, user support, and vendor management. Distinguish accountable from consulted. A vendor may operate a hosted control plane while the customer remains accountable for failed actions against cloud accounts. A systems integrator may deliver connectors but not maintain them through API changes.
Backstage illustrates the distinction. It is an open source framework for building developer portals, powered by a catalog and extensible through plugins and templates. Adopters assemble and operate an application; a plugin ecosystem does not imply that every integration is maintained, security-reviewed, or compatible with the adopter's release. A managed Backstage offering may transfer hosting and upgrade duties, but local metadata, authorization policy, and custom workflow behavior still need owners.
Build a five-year labor and change model
Estimate effort by recurring work queue, not one launch headcount. Include platform product management, design and research, software engineering, site reliability, security review, documentation, user enablement, data stewardship, support, procurement, and finance. Model coverage and concentration risk: one engineer who understands every connector is not a resilient operating model. Apply local loaded labor rates and hiring lead time rather than generic industry estimates.
Then model change. How many identity, cloud, CI, source-control, observability, and ticketing APIs will evolve? How many platform releases, provider updates, runtime retirements, acquisitions, and policy changes are plausible? Purchased products create vendor upgrade work and extension compatibility testing; built products create dependency, framework, and infrastructure upgrades. Neither path freezes the environment. Use low, expected, and high scenarios and state assumptions.
| Cost category | Build-heavy evidence | Buy-heavy evidence | Sensitivity driver |
|---|---|---|---|
| Initial delivery | Architecture, core code, hosting, UX | Procurement, configuration, migration | Scope and existing foundations |
| Integration | Connector and workflow engineering | Vendor connectors plus local extensions | Number and volatility of systems |
| Steady operations | SRE, databases, upgrades, support | Subscription plus customer administration | Availability and support expectations |
| Change | Roadmap and dependency modernization | Edition changes, vendor releases, extension rework | Annual platform and policy change |
| Risk | Security debt and key-person concentration | Supplier, tenancy, roadmap, and outage exposure | Control requirements |
| Exit | Documentation and handover | Data export, workflow replacement, contract termination | Portability of contracts and state |
Test integration and extension boundaries
Ask candidates to implement one representative journey across real nonproduction systems, including a policy denial and a partial failure. Inspect authentication context, secret handling, retries, idempotency, audit events, rate limits, and error messages. Determine where custom code runs, how it is deployed, what SDK compatibility is promised, and who debugs it. A visual workflow builder can still conceal an application that your team must version, test, and operate.
Evaluate escape hatches. Can teams invoke the same platform contract through API or CLI when the portal is unavailable? Can orchestration call existing modules without forking them? Can custom fields and plugins survive upgrades? Does extension code receive broad customer credentials? Backstage's permission framework supports policy decisions, but documentation notes that authorization must be configured; the presence of a framework is not the same as an enforced local model.
Evaluate data, security, and failure domains
Inventory data the platform stores or observes: source metadata, user identity, cloud resource details, logs, deployment state, secrets, cost, vulnerabilities, and incident links. Define residency, tenancy, encryption, retention, deletion, export, and support-access requirements. Review service identities and downstream permissions. A central platform can become a high-value control plane even if it never handles application customer data.
Model outages by dependency. If the portal fails, can delivery continue through documented interfaces? If the vendor control plane, customer runner, catalog database, identity provider, source host, or cloud API fails, what remains readable and writable? Test backup restoration and degraded operation. Vendor availability commitments should map to user journeys and dependencies, not only the hosted UI. Include incident notification, evidence access, and shared troubleshooting obligations in the contract.
Price upgrades and support with real scenarios
Review release cadence, support windows, breaking-change policy, security backports, maintenance scheduling, sandbox availability, and rollback. Ask for evidence from two recent upgrades, including customer actions and extension changes. For self-operated software, automate upgrade tests against catalog ingestion, critical templates, permissions, and plugins. For SaaS, determine whether changes can be delayed, previewed, or feature-gated and what happens to custom APIs.
Define tiered support. Developers need help with platform use; platform operators need product diagnostics; security and procurement need evidence; incident teams need time-bound escalation. Measure who owns first response and how issues cross the vendor boundary. A premium vendor SLA does not eliminate the customer's internal support desk, and an internal build does not require every product team to diagnose the platform itself.
Make exit a tested architecture property
List portable assets: workload contracts, source repositories, templates, catalog descriptors, entity history, workflow definitions, audit events, policy, resource identities, and documentation. Obtain export formats and API limits. Distinguish data export from executable portability; a JSON workflow may be unusable elsewhere. Keep organization intent in stable schemas where possible and isolate vendor adapters behind platform-owned interfaces.
Run a small exit drill before signing or scaling. Export a catalog cohort, reproduce one workflow through an alternative mechanism, revoke vendor access, and measure the gaps. Contract for transition assistance, deletion evidence, continued security fixes during notice, and access to logs. For an internal build, perform a maintainership handover to prove that architecture and runbooks are not trapped with the founding team.
Make a reversible, evidence-based decision
- Define priority journeys, eligible users, controls, and outcome baselines.
- Map every capability and recurring obligation to an accountable party.
- Run the same real integration and failure scenario for shortlisted approaches.
- Model five-year labor, commercial cost, change, risk, and exit under three scenarios.
- Pilot with representative teams and measure task success, support, reliability, and adoption.
- Record assumptions, decision triggers, contract protections, and a reassessment date.
Key takeaways
- Compare the same bounded platform journeys, not product labels.
- Price recurring ownership, integration, change, security, and support.
- Use real failure scenarios to expose extension and responsibility boundaries.
- Treat catalog data and internal product management as retained obligations.
- Test data and workflow exit before dependence becomes expensive.
Frequently asked questions
Does buying an IDP eliminate the platform team?
No. It may reduce hosting or feature engineering, but user research, roadmap, integration ownership, metadata quality, policy, support, and outcome measurement remain. Team shape changes according to which operational duties the supplier actually accepts.
Is Backstage a build decision?
Backstage is a framework that can anchor a build-heavy portal approach or be consumed through a managed offering. Evaluate the concrete operating model: hosting, release management, plugins, catalog governance, security, customization, and support, not the framework name alone.
How should vendor features be scored?
Score their contribution to priority journeys and the obligation they remove. Verify with working evidence, failure behavior, maintainability, and commercial terms. A feature with no accountable use case adds upgrade and cognitive burden rather than value.
Conclusion
The strongest IDP choice is the operating model the organization can sustain, not the longest feature list. Define the platform contract, expose retained responsibilities, test integrations and failures, price change over years, and preserve exit. With that evidence, build, buy, and hybrid options become comparable investments rather than competing demos.