Platform Engineering: Internal Developer Platforms, Golden Paths, Score and Crossplane in Practice

Most organizations that adopt platform engineering do not fail because they picked the wrong tool. They fail because they built a portal, put a form on top of the same ticket queue, and called it self-service. Six months later the platform team is a bottleneck with a nicer front end, and developers quietly go back to copying Terraform from the last project that worked.

This matters in 2026 because the number of things a product team is expected to own keeps growing: Kubernetes, cloud services, supply-chain security, cost, and now AI tooling. An internal developer platform (IDP) is the standard answer, but the term covers everything from a Backstage catalog to a full orchestration layer.

This guide separates the layers. You will leave with a reference architecture, a clear view of what Score and Crossplane each do, a worked golden-path example in YAML, a way to measure the platform with DORA metrics, a build-versus-buy matrix, and a list of anti-patterns that kill adoption.

What this covers: platform-as-product thinking, the IDP reference architecture, golden paths versus paved roads and guardrails, Score and Crossplane in depth, Backstage and CNOE, measurement, the maturity model, build-versus-buy, and what goes wrong.

Context and Background

Platform engineering is the practice of planning and providing computing platforms to developers and other internal users. That is the definition used by the CNCF platforms white paper and its companion maturity model, and it is deliberately broad: a platform “curates and presents common capabilities, frameworks, and experiences” for internal users such as product and application teams. The key word is curates. A platform is not a pile of infrastructure access; it is a selected, supported subset of it.

The idea did not arrive from nowhere. DevOps removed the wall between development and operations, but it often did so by asking every product team to become a part-time infrastructure team. The result was predictable: dozens of teams each owning their own CI pipelines, Helm charts, IAM policies, and Terraform modules, with wildly different quality. Team Topologies, the organizational model by Matthew Skelton and Manuel Pais, gave the pattern a name. It defines four team types (stream-aligned, platform, enabling, and complicated-subsystem) and three interaction modes (collaboration, X-as-a-Service, and facilitation). A platform team exists to provide an internal product that speeds up stream-aligned teams through the X-as-a-Service mode, with minimal interaction and clear boundaries.

The second pillar is cognitive load. Team Topologies argues that each new tool, responsibility, or domain consumes a team’s mental capacity, and that overloaded teams make poorer decisions and slow down. This is the real justification for a platform. It is not primarily about saving infrastructure hours; it is about removing decisions that do not differentiate the product. The related concept of a thinnest viable platform (TVP) says a platform should provide only the capabilities needed, because “a good platform should make stream-aligned teams move faster, not generate more dependencies to manage.”

The tooling landscape matured around this idea. Backstage, created at Spotify and now a CNCF incubating project, provides a software catalog, software templates, and TechDocs. Crossplane turns Kubernetes into a control plane for cloud resources. Score, a CNCF sandbox project, offers a platform-agnostic workload specification. CNOE (Cloud Native Operational Excellence), a collaboration among companies including Siemens, AWS, Adobe, Autodesk, Twilio, Salesforce, Intuit, Nike and Cisco, publishes IDP reference architectures built from open source projects. For a hands-on view of the portal layer, see our Backstage production setup guide.

The part the tools do not solve is the organizational one. A platform is a product with customers who can leave. Treating it that way is the single biggest predictor of whether the rest of this article works.

Platform as a product

Product thinking changes concrete behavior. A platform team keeps a roadmap driven by user research, not by the infrastructure team’s preferences. It defines who its users are (application developers, data engineers, ML engineers, and now automated agents), interviews them, and tracks adoption and satisfaction. It writes documentation as a product surface, and it has a deprecation policy.

It also changes how the team talks about mandates. The CNCF maturity model describes adoption moving from erratic, through extrinsic push such as mandates and incentives, to intrinsic pull where users choose the platform because it is better. Mandates are a legitimate bootstrapping tool at level two, but a platform that depends on them at level three has a product problem.

The IDP Reference Architecture

An internal developer platform is a layered system that turns a developer’s declared intent into running, observable, compliant infrastructure, with the platform team owning the layers and developers owning only the intent. The five planes are: developer interface, platform API, orchestration, infrastructure and delivery, and observability with feedback.

Figure 1: IDP reference architecture. Developers and agents interact with a portal or CLI, declare intent through Score or a Crossplane composite resource, and an orchestration layer fans out to IaC and GitOps engines. Telemetry returns to the platform team as product feedback.

The diagram reads top to bottom. A developer or an AI agent starts at the portal or the command line. The request becomes a declarative artifact, either a Score workload file or a composite resource, that passes through an orchestration step which resolves what the workload needs. Infrastructure is realized by an IaC engine such as Crossplane or Terraform, while the runtime is reconciled by a GitOps controller such as Argo CD or Flux. Observability and cost data flow back, and the platform team uses that signal to decide what to build next.

Plane 1: developer interface

The interface is where developers meet the platform. Usually this is a portal (Backstage being the most common open source choice), a CLI, and templates that scaffold new services. The important design point is that the portal is a view, not the platform. If the only way to provision a database is to click through the portal, you have built a GUI on top of a ticket queue. A durable platform exposes the same capability through an API and a Git-based declaration, so that the portal, the CLI, and CI jobs all call one contract.

The CNOE reference architecture follows the same split, treating the portal as one replaceable component among open source building blocks, and stating that the stack should be modular so users can choose which core technologies to use.

Plane 2: platform API and the workload contract

The platform API is the most underrated layer. It answers one question: what does a developer have to write to get a service running? There are two broad philosophies.

The first is the resource-centric contract, where developers declare Kubernetes-style custom resources such as a Database or a Bucket. This is the Crossplane model. The second is the workload-centric contract, where developers describe their application and what it needs, and the platform maps that to environment-specific infrastructure. This is the Score model. They are not mutually exclusive, and the strongest designs use workload-centric declarations on top and resource-centric abstractions underneath.

Plane 3: orchestration

Orchestration resolves the contract against the environment. When a developer says “my service needs a Postgres database,” something must decide whether that means a container in a local Docker Compose stack, a shared instance in dev, or a managed multi-AZ cluster in production. Humanitec’s Platform Orchestrator is the best-known commercial implementation of this idea; its documentation lists Score, Resources, Resource Definitions and Resource Classes as the core concepts. The open source Score implementations (score-compose and score-k8s) do a lighter version of the same resolution for local and Kubernetes targets.

You can also build orchestration from Git pipelines, templating, and Crossplane compositions. The critical property is not the product but the separation: developers declare what, the platform decides how, per environment.

Plane 4: infrastructure and delivery

Two engines do the work. The IaC engine provisions cloud resources. Crossplane does this through Kubernetes controllers and continuous reconciliation, while Terraform or OpenTofu do it through plan and apply cycles. Our guide to Terraform state management and drift detection at scale covers the pipeline mechanics if your platform leans that way.

The delivery engine moves desired state into clusters. GitOps controllers pull from Git, so the repository is the audit log. If you are choosing between controllers, the trade-offs are laid out in our Argo CD versus Flux decision record.

Plane 5: observability and feedback

A platform without usage data is run on opinion. At minimum you want, per golden path, the count of services created, time from template to first production deploy, the DORA delivery metrics for those services, and cost per service. This plane closes the loop in Figure 1: the platform team reads these signals and prioritizes.

Golden Paths, Paved Roads and Guardrails

These three terms are used interchangeably and should not be. They describe different amounts of coercion, and the choice between them is a product decision.

A golden path is an opinionated, supported, end-to-end route for a common task, such as “create a stateless HTTP service with a Postgres database and a pipeline.” It is easy to start, well documented, and maintained by the platform team. The original framing, popularized at Spotify, is that golden paths are the easiest option, not the only option.

A paved road is a golden path that has been hardened to the point where the organization strongly prefers it. Netflix popularized the paved-road phrase. Leaving the road is allowed but means you own what the platform would have owned: patching, compliance evidence, and on-call.

A guardrail is a policy that applies to everyone regardless of path: no public buckets, images only from approved registries, mandatory resource limits. Guardrails are enforced by admission controllers and policy engines, and they protect the organization when someone leaves the path.

Concept	Coercion	Who maintains	Typical enforcement	Failure mode
Golden path	Low, easiest option	Platform team	Defaults and templates	Too narrow, nobody fits
Paved road	Medium, preferred	Platform team	Support boundary, audit evidence	Becomes a mandate in disguise
Guardrail	High, applies to all	Platform plus security	Admission control, policy as code	Blocks without explaining why

The practical rule is to keep golden paths cheap to leave and guardrails cheap to understand. A guardrail that rejects a deploy with an opaque error generates a support ticket, which is exactly the load the platform was meant to remove. Every policy failure should say what rule fired, why it exists, and how to fix it.

Why forced adoption backfires

Mandates create the appearance of success. Adoption dashboards go green while developers work around the platform: creating clusters from personal accounts, bypassing the template, or forking the pipeline. The CNCF model’s distinction between extrinsic push and intrinsic pull is useful here. If you find yourself needing to mandate, ask what the path lacks. Usually it is one of three things: it is slower than the manual route, it does not cover a real use case, or its failure messages are unreadable.

Score: A Workload Contract for Developers

Score describes a workload once and lets different platforms interpret it. The project describes itself as a developer-centric and platform-agnostic workload specification that keeps configuration consistent between local and remote environments. It is a CNCF sandbox project, and its files use apiVersion: score.dev/v1b1.

Figure 2: A Score file contains only the workload. The orchestrator combines it with platform-owned rules per environment to produce manifests and resource requests, which Crossplane realizes as managed resources.

A Score file has four parts that matter. metadata.name identifies the workload. containers define images and environment variables. service.ports declares named ports. resources declare abstract dependencies by type, such as postgres, and variables can reference them with expressions like ${resources.db.host}. Notably absent: replica counts, node selectors, storage classes, IAM roles. Those belong to the platform.

The two open source implementations show the idea. score-compose takes score.yaml and generates a Docker Compose file for local development. score-k8s generates Kubernetes manifests for a cluster. Both follow an init, generate, apply cycle. The same developer file thus drives a laptop and a cluster, which removes the classic mismatch between “works in compose” and “works in staging.”

What Score is not

Score is not a deployment tool, a portal, or an infrastructure provisioner. It does not try to model every Kubernetes feature. This is a deliberate limitation, and it is the source of both its strength and its friction. Because it only covers the common denominator, advanced needs (custom sidecars, unusual scheduling, StatefulSet semantics) must be handled by platform-side patches, workload profiles, or by leaving the Score path. Teams evaluating Score should list what fraction of their services fit the common denominator before committing. If it is 90 percent, Score is a good fit. If it is 40 percent, you are building an escape hatch that most teams will use.

The Humanitec Platform Orchestrator relationship

Score originated at Humanitec and is positioned in that vendor’s materials as the open source, code-based interface of an IDP, while the Platform Orchestrator is a commercial, graph-based backend that resolves Score workloads against resource definitions. The relationship matters for lock-in analysis: the Score file is portable, while the resource definitions and orchestration logic are where vendor-specific investment accrues. Verify the current product packaging and naming on the vendor’s site before you plan around it, since these have changed over time.

Crossplane: Compositions as the Infrastructure API

Crossplane lets a platform team define its own infrastructure API in Kubernetes and implement it with composable building blocks. It is the resource-centric half of the design.

Three concepts carry the model. A Composite Resource Definition (XRD) declares a custom API: the schema developers fill in. A Composite Resource (XR) is an instance of that API. A Composition is the implementation: a template that defines how to create multiple managed resources as one object, limited by compositeTypeRef to a particular XR type.

Modern compositions are pipelines of composition functions. Per the Crossplane documentation, a Composition uses mode: Pipeline, and the older mode: Resources is deprecated. Functions are gRPC servers called in order; common choices include Go templates, KCL, CUE, and Patch and Transform, and you can write your own in Go or Python. Each function receives the desired state produced so far and must carry forward anything it does not change, or Crossplane deletes it. That last rule is a classic first-week trap.

Crossplane v2 changes that matter for platforms

The v2 line (the documentation’s current version at the time of writing is v2.4) changed several things that affect platform design:

XRs are namespaced by default. XRDs gained a scope field that defaults to Namespaced, with Cluster available for cluster-scoped XRs.
New namespaced and cluster-scoped XRs do not support claims. Legacy XRs defined with the v1 XRD API keep claims under a LegacyCluster scope.
XRDs use apiextensions.crossplane.io/v2.
Managed resources are namespaced; cluster-scoped managed resources are legacy and slated for later removal.
Compositions can include any Kubernetes resource, including third-party custom resources, provided Crossplane is granted access.
Native patch-and-transform, ControllerConfig, external secret stores and XR connection details were removed.
Operations (run-once, scheduled, or watch-triggered function pipelines) exist as an alpha feature.

Namespaced XRs are good news for platform design. A developer team can be given RBAC in its own namespace and create a Database XR there, without the claim indirection that existed before. If you built on claims with v1, plan a migration rather than assuming a drop-in upgrade; the project provides crossplane beta upgrade check to scan a v1 control plane.

A minimal XRD and Composition

The following sketch shows the shape of a Database API with a single size field. The composed resource kind and provider group are illustrative and must be matched to the provider package you actually install.

apiVersion: apiextensions.crossplane.io/v2
kind: CompositeResourceDefinition
metadata:
  name: xdatabases.platform.example.org
spec:
  scope: Namespaced
  group: platform.example.org
  names:
    kind: XDatabase
    plural: xdatabases
  versions:
    - name: v1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                size:
                  type: string
                  enum: [small, medium, large]
              required: [size]
---
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: xdatabase-aws
spec:
  compositeTypeRef:
    apiVersion: platform.example.org/v1
    kind: XDatabase
  mode: Pipeline
  pipeline:
    - step: render
      functionRef:
        name: function-go-templating
      input:
        apiVersion: gotemplating.fn.crossplane.io/v1beta1
        kind: GoTemplate
        source: Inline
        inline:
          template: |
            # Render provider-specific managed resources here,
            # mapping size small|medium|large to instance classes.
    - step: ready
      functionRef:
        name: function-auto-ready

Treat the Go template body as a placeholder; the point is the contract. Developers see size: small | medium | large. The platform team maps those to instance classes, subnets, backup windows, encryption keys, and tags, and can change the mapping without touching a single application repository.

Where Crossplane hurts

Crossplane shifts complexity rather than deleting it. You now operate a control plane that must be upgraded, whose provider packages track cloud APIs, and whose reconciliation behavior (including how it adopts or deletes external resources) must be understood before production. Debugging a composition means reading status conditions across several layers. Teams without Kubernetes depth often find Terraform with a well-designed module catalog and a pipeline simpler to run. Choose Crossplane when continuous reconciliation, Kubernetes-native RBAC, and an API-first model are worth the operational cost.

A Worked Golden Path: From Template to Production

The path below ties the layers together. A developer picks a template in the portal, and everything else follows from Git.

Figure 3: Golden path sequence. The portal template creates a repository containing score.yaml, CI builds and commits rendered manifests, and the GitOps controller reconciles the cluster. The developer receives a URL and dashboards.

Step by step:

Template. The developer selects “HTTP service with Postgres” in the portal. The template asks for a name, a team, and a language. Nothing about clusters or regions.
Repository. The portal creates a repo from a skeleton containing source, a Dockerfile, a CI workflow, and a score.yaml.
Build. Push triggers CI, which builds and scans the image, then runs the Score implementation to render environment-specific manifests.
Commit. CI commits rendered manifests, or an image tag bump, to a deployment repository.
Reconcile. Argo CD or Flux pulls the change and applies it. A postgres resource request becomes a Crossplane XDatabase in that environment.
Feedback. The developer receives the service URL, a default dashboard, and an on-call routing entry.

The workload file the developer owns looks like this:

apiVersion: score.dev/v1b1
metadata:
  name: orders-api
containers:
  api:
    image: registry.example.org/shop/orders-api:latest
    variables:
      DB_HOST: ${resources.db.host}
      DB_PORT: ${resources.db.port}
      DB_NAME: ${resources.db.name}
      DB_USER: ${resources.db.username}
      DB_PASSWORD: ${resources.db.password}
service:
  ports:
    http:
      port: 80
      targetPort: 8080
resources:
  db:
    type: postgres

Everything environmental is absent. On a laptop, score-compose generate can resolve postgres to a container. In production, platform rules resolve the same declaration to a managed instance through an XR like the one above. The field names under resources.db depend on the provisioner that implements the postgres type, so confirm the output keys in your implementation before relying on them. In the example above, treat the variable names as illustrative.

The tag :latest is also illustrative; in a real pipeline CI substitutes an immutable digest. Pinning matters for the audit trail, since GitOps is only as trustworthy as the artifacts it references.

Guardrails around the path

The path is wrapped in policy. Admission control (for example Kyverno or OPA Gatekeeper) enforces non-root containers, resource limits, and approved registries. Crossplane compositions encode non-negotiables such as encryption at rest and private networking, so a developer cannot omit them by forgetting a field. Because defaults live in the composition, security improves for every existing service when the platform team updates it.

Traffic and networking

Most golden paths hide networking behind a single field such as exposure: internal | public. Behind it the platform picks an ingress or gateway, issues certificates, and wires DNS. If your cluster uses eBPF-based networking, the interplay of network policy and the service mesh is worth understanding; see our guide on Cilium and sidecarless service mesh for the underlying mechanics.

Measuring the Platform

If you cannot show that the platform improved delivery, you will lose the budget argument. There are two measurement families: delivery outcomes and platform product metrics.

DORA delivery metrics

DORA’s current model has five software delivery metrics, split into throughput and instability. Throughput comprises change lead time (commit to production), deployment frequency, and failed deployment recovery time, which replaced the older mean time to restore. Instability comprises change fail rate and deployment rework rate. DORA’s guidance is that, for most teams, speed and stability are not trade-offs; high performers do well on all five.

Use these at the level of golden path or service cohort, not individual teams. Compare services on the path against services off it, and be honest about selection bias: teams that adopt early are usually the better-run ones. A before and after view for the same service, taken at migration, is a more defensible comparison.

DORA’s 2025 report framed AI as an amplifier of an organization’s existing strengths and weaknesses, and says the biggest returns come from investing in the underlying organizational system rather than the tools. That is a direct argument for a platform: a reliable pipeline, fast feedback, and clear contracts are exactly what let AI-assisted changes land safely. I did not verify the report’s specific platform-engineering statistics in the primary source, so this article does not quote them.

Platform product metrics

DORA tells you whether delivery is healthy. It does not tell you whether the platform caused it. Add product metrics:

Adoption: share of new services created through a golden path, and share of production services on supported paths.
Time to first deploy: minutes from template selection to a running service in a non-production environment.
Time to production readiness: days until a service passes security, observability, and ownership checks.
Support load: tickets or chat requests per developer per month, and the share that are repeat questions.
Developer satisfaction: a short recurring survey with a net promoter style question and a free-text field.
Cost per service: cloud spend attributed through tags that compositions apply automatically.

Be careful with vanity metrics such as portal page views. A healthy platform may have fewer portal visits over time because the path is automatic.

Cognitive load as a measurable signal

Cognitive load is hard to measure directly, but proxies exist: number of distinct tools a developer touches to ship a change, number of approval hops, and the answer to a survey item such as “I know where to find what I need to ship.” Track the first two during a path audit by literally walking the journey and counting clicks, tools, and waiting states. The count is often shockingly high and makes a persuasive slide.

The Platform Maturity Model

The CNCF platform engineering maturity model assesses five aspects independently across four levels. It is explicitly a tool for finding improvements, not a ranking; the white paper notes that reaching the top level should not be the goal in itself since higher levels require more investment.

Figure 4: The four maturity levels (Provisional, Operationalized, Scalable, Optimizing) with the adoption pattern at each level.

Aspect	Provisional	Operationalized	Scalable	Optimizing
Investment	Voluntary or temporary	Dedicated team	Managed as a product	Enabled ecosystem
Adoption	Erratic	Extrinsic push	Intrinsic pull	Participatory
Interfaces	Custom processes	Standard tooling and golden paths	Self-service solutions	Integrated services
Operations	By request	Centrally tracked	Centrally enabled	Managed services
Measurement	Ad hoc	Consistent collection	Insights	Quantitative and qualitative

Note that the white paper’s table header calls level two “Operational” while its detailed text calls it “Operationalized”; the meaning is the same.

Use the matrix as a conversation tool. Score each row honestly, then look for the largest gap between aspects. A very common pattern is an organization with level-three interfaces (good self-service) but level-one measurement, which means nobody can prove the platform works. Another is level-two adoption by mandate sitting on top of level-one operations, where every request still goes through a person. Fix the weakest aspect that is blocking the others.

Build versus Buy

The question is rarely “build everything” or “buy everything.” It is which layers differentiate you and which are commodity.

Layer	Build on open source	Buy or use managed	Notes
Portal	Backstage	Managed Backstage or commercial portals	Backstage is a framework, not a product; budget for engineers
Workload spec	Score	Vendor spec	Score file is portable, so lock-in risk is low
Orchestration	Pipelines plus Crossplane	Commercial orchestrator	Highest leverage and highest lock-in
Infrastructure API	Crossplane compositions, Terraform modules	Cloud-native service catalogs	Choose by team skill
GitOps	Argo CD, Flux	Managed GitOps offerings	Mature, rarely worth building
Policy	Kyverno, OPA	Commercial policy suites	Start with open source
Observability	OpenTelemetry stack	SaaS observability	Usually buy

A defensible rule: buy or adopt commodity, build the glue that encodes your organization’s rules. Compositions, templates, and policies are your intellectual property. A portal frame is not.

Weigh team size honestly. Backstage is powerful but, as its own positioning shows (a framework that organizations extend with plugins), it needs dedicated frontend and platform engineers. For organizations with fewer than a few dozen developers, a repository of templates, a CLI, and good documentation often delivers most of the value at a fraction of the cost. The CNOE reference architectures can shorten the path for larger organizations by showing proven combinations of open source components.

Trade-offs, Gotchas, and What Goes Wrong

The ticket-ops portal. A portal whose forms create tickets for a human is not self-service. Test it: if provisioning requires a person in the loop for the common case, you have a queue with a UI. Reserve human approvals for genuinely risky actions and automate the rest with policy.

Forced adoption. Covered above. If the only reason developers use the platform is a mandate, expect shadow infrastructure and resentment. Fix the product, then lower the pressure.

Building the platform before knowing the users. Teams spend a year on a Kubernetes abstraction nobody asked for. Start with the highest-friction journey, usually “new service to production,” and ship a thin path in weeks. This is the thinnest viable platform idea in practice.

Abstraction that leaks. If developers must read Crossplane status conditions or kubectl events to understand a failure, the abstraction has failed. Invest in error surfaces: translate low-level failures into actionable messages in the portal or CLI.

Lock-in through the leaky middle. A portable workload file does not help if your orchestration rules, resource definitions, and custom plugins cannot move. Document which layers are portable and which are not before signing a contract.

Platform team as a bottleneck. When every new capability needs the platform team, the team becomes the constraint. Move toward a contribution model, which the maturity model describes at its top level as users and specialists contributing, with clear interfaces and review ownership.

Upgrade debt. Backstage, Crossplane, and provider packages all move quickly; Crossplane v2 removed several v1 features outright. Budget a regular upgrade cadence and a staging control plane. A platform that falls three versions behind becomes frozen.

Security blind spots. Platform credentials are high-value. A control plane that can create any cloud resource is a privileged target. Scope provider credentials per environment, separate production control planes, and audit who can change compositions.

Measuring the wrong thing. Counting templates created without asking whether services reached production, or celebrating deployment frequency while change fail rate rises. Always read throughput and instability together.

Practical Recommendations

Start small, with one journey, and ship it in weeks. Interview ten developers, walk the current path and count the hops, then pick the single journey with the highest friction. Almost always this is “new stateless service with a database to production.”

Define the contract before the tooling. Decide what a developer writes (a Score file, a composite resource, or a plain YAML template), and keep it free of environment detail. Then pick the orchestrator and portal that fit that contract, not the other way around.

Make the platform the easiest path, then measure it. Baseline DORA metrics for a pilot cohort before migration, track adoption by pull rather than mandate, and publish the numbers internally. Staff the team as a product team, with a product manager or at least a named owner who talks to users every week.

A checklist to run before you call a path “golden”:

A developer can go from template to production without filing a ticket for the common case.
The path is documented with a runnable example and a clear support boundary.
Policy failures explain the rule, the reason, and the fix.
Defaults for security, tagging, backup, and observability live in compositions or templates, not in developer docs.
There is a way off the path that is possible, documented, and honestly costed.
You have a baseline for lead time, deployment frequency, and change fail rate.
Someone owns the roadmap, and there is a deprecation policy.
You have a staging control plane and a scheduled upgrade cadence.

Finally, revisit the maturity matrix every two quarters. The goal is not a higher level but a shorter list of known gaps.

Frequently Asked Questions

What is platform engineering?

Platform engineering is the practice of planning and providing computing platforms for internal users such as product and application teams. A platform team curates a supported set of capabilities (infrastructure, delivery pipelines, security defaults, observability) and exposes them as self-service products. The aim is to reduce cognitive load on stream-aligned teams so they can ship faster without each re-solving the same infrastructure problems, while the organization keeps consistent security and compliance.

What is an internal developer platform?

An internal developer platform is the concrete system a platform team builds to deliver those capabilities. It typically combines a developer interface (portal, CLI, templates), a platform API or workload contract, orchestration that resolves intent per environment, IaC and GitOps engines, and observability feedback. Backstage is a common portal, Score a workload spec, and Crossplane a way to define infrastructure APIs. The platform, not the portal, is the product.

What is the difference between a golden path and a paved road?

A golden path is an opinionated, supported route for a common task that is meant to be the easiest option. A paved road is a golden path hardened to the point where the organization strongly prefers it, with leaving it carrying the cost of owning what the platform would have owned. A guardrail is different again: a policy applied to everyone regardless of route, enforced by admission control or policy as code.

Do I need Backstage to do platform engineering?

No. Backstage is a framework for building developer portals, with a software catalog, software templates and TechDocs, and it is a CNCF incubating project. It is valuable at scale but requires dedicated engineering investment. A small organization can deliver most of the value with repository templates, a CLI, GitOps, and good documentation. Start with the golden path and add a portal when discoverability or catalog needs justify it.

How do Score and Crossplane relate?

They address different layers. Score is a platform-agnostic workload specification: developers declare containers, ports and abstract resource needs such as a postgres database. Crossplane lets a platform team define infrastructure APIs and implement them with compositions. Together, an orchestrator resolves a Score resource request into a Crossplane composite resource, which compositions turn into managed cloud resources. Score is the developer contract; Crossplane is one possible implementation underneath.

How do I measure whether a platform is working?

Combine DORA’s five delivery metrics (change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate) with platform product metrics: adoption by pull, time to first deploy, support load, developer satisfaction and cost per service. Compare cohorts carefully, since early adopters are usually stronger teams, and prefer before and after views for the same services. Read throughput and instability together.