I'm planning to build an Internal Developer Platform proof of concept mainly for self-learning, with the possibility of using the results to make a business case at my company later. I want to understand the practical pieces involved in developer experience and self-service before committing to a large collection of tools.
I'm particularly interested in what people are running successfully in production for service catalogues, infrastructure provisioning, workload orchestration, GitOps, and developer self-service. If you were building a lightweight platform from scratch today, which open-source tools would you choose to demonstrate meaningful value without creating a maintenance project?
I'm considering combining a developer portal with a GitOps engine and a basic infrastructure module framework. I'd also like to know whether tools such as Backstage, Kratix, Port, Crossplane, Terraform, or similar products have delivered measurable time savings in practice, and which tools turned out to add more overhead than value.
For the business case, I'm planning to measure the current time and number of handoffs involved in going from a new repository to a running service, including development, staging, and production environments. Any advice on useful metrics or a practical PoC scope would be appreciated.
4 Answers
The technology stack is only half of the business case. Measure the current process before changing it, using several recent services as examples. Useful numbers include the time from repository creation to a running production service, the time to obtain a complete development or preview environment, the number of teams or people involved, and how often work waits in another team’s queue. Then build the PoC around the biggest bottleneck. If developers can create a standard service, deploy it through equivalent environments, and provision the required dependencies without opening a platform ticket, you’ll have a much stronger demonstration than a collection of disconnected tools.
A practical starting stack would be Backstage for the catalogue, Argo CD or Flux for GitOps, and Crossplane or an infrastructure-as-code tool for provisioning. Avoid building a custom portal initially; the interface is easy to underestimate and can consume months of work. If you want to demonstrate higher-level self-service workflows, Kratix can help package multiple resources behind a simpler platform API. Keep the first version narrow: one service template, one deployment path, and one environment-creation workflow.
This combination gives me a useful starting point. I’ll also compare the Flux and OpenTofu Controller approach before deciding which path is simpler for the PoC.
Be careful about making Backstage the centre of the project just because it is popular. It works well as a catalogue when there are people responsible for maintaining integrations, but an empty or stale catalogue quickly becomes useless. For the write path, choose one provisioning system rather than layering several of them together. Kubernetes can handle workload orchestration if it is already part of your environment, while a portal such as Backstage, Port, or Kratix should only be added when it makes a real workflow easier for developers. A meaningful PoC should let someone create a service and obtain a usable preview environment through one path; counting plugins is not a useful success metric.
I’ve worked through a similar Backstage-based setup. The basic catalogue is fairly approachable, but connecting real clusters and making software templates perform useful, reliable actions becomes complicated quickly. Documentation integration also tends to take longer than expected. That complexity is valuable for learning, but budget more time for the integration and operational work than for the initial installation. For a small proof of concept, I’d avoid trying to represent every type of service or infrastructure resource.
That’s helpful. I’m leaning toward using Backstage only for a small catalogue and a single template first, rather than treating it as a complete platform from day one.
I agree that repository-to-production is only one measure. I’d also track repository creation through the initial application stack, plus how quickly an engineer can create another equivalent environment without needing a separate DevOps or platform request. That captures the repeatability benefit more accurately.