Platform engineering is the fastest-growing discipline in DevOps right now. Gartner says 80% of large engineering organisations will have a platform team by the end of 2026. There are two ways startups respond to this: they ignore it, or they build an elaborate developer portal when they have 12 engineers.
Both are wrong. Here is when it actually matters and what to build first.
What Platform Engineering Actually Is
Platform engineering is the practice of building internal products - tools, workflows, and abstractions - that let your engineering teams deploy and operate software without needing DevOps expertise.
The output is an Internal Developer Platform (IDP): a collection of self-service capabilities (deploy a service, provision a database, get monitoring, rotate a secret) that engineers can use without opening a Jira ticket or waiting for a DevOps engineer.
It is not a Backstage install. Backstage is a service catalog - it lists what you have. The IDP is the automation behind the catalog. Backstage without automation is just documentation with extra steps.
The Real Signal: When to Invest
You do not need platform engineering yet if:
- •You have fewer than 20 engineers
- •Your team can answer "what's running in production?" in under 5 minutes
- •Deployments happen less than 5 times a day across all services
- •One person still has a reasonable mental model of all the infrastructure
You need platform engineering if any of these are true:
- •Engineers open DevOps tickets to do things they could do themselves with the right tooling
- •New engineers take more than 2 weeks to get their first PR into production
- •You have more than 5 microservices and no clear way to spin up a new one consistently
- •Your senior engineers spend more than 30% of their time answering infrastructure questions
- •Deployments are inconsistent across services - some teams have CI, some deploy manually
The inflection point is usually 30–50 engineers or 10+ microservices.
What to Build First: The Golden Path
The highest-ROI starting point is a Golden Path - a template-based, opinionated way to create and deploy a new service. When an engineer wants to start a new microservice, they should be able to run one command and get:
- •A GitHub repository with a working CI/CD pipeline
- •A Dockerfile and Helm chart
- •A Kubernetes namespace
- •Monitoring (ServiceMonitor configured)
- •Logging (log aggregation working by default)
- •A staging environment that gets automatically deployed on main merge
Here is a minimal golden path using GitHub repository templates and a setup script:
bash#!/bin/bash # create-service.sh SERVICE_NAME=$1 TEAM=$2 if [ -z "$SERVICE_NAME" ] || [ -z "$TEAM" ]; then echo "Usage: ./create-service.sh <service-name> <team-name>" exit 1 fi echo "Creating service: $SERVICE_NAME for team: $TEAM" # 1. Create GitHub repo from template gh repo create "your-org/$SERVICE_NAME" \ --template "your-org/service-template" \ --private # 2. Provision Kubernetes namespace kubectl create namespace $SERVICE_NAME kubectl label namespace $SERVICE_NAME team=$TEAM # 3. Create Argo CD Application cat <<EOF | kubectl apply -f - apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: $SERVICE_NAME namespace: argocd spec: project: $TEAM source: repoURL: https://github.com/your-org/$SERVICE_NAME targetRevision: HEAD path: helm destination: server: https://kubernetes.default.svc namespace: $SERVICE_NAME syncPolicy: automated: prune: true selfHeal: true EOF # 4. Create initial secrets placeholder kubectl create secret generic $SERVICE_NAME-config \ --from-literal=placeholder=configure-me \ --namespace=$SERVICE_NAME echo "Done. Service $SERVICE_NAME is ready." echo "Repo: https://github.com/your-org/$SERVICE_NAME" echo "ArgoCD: https://argocd.yourdomain.com/applications/$SERVICE_NAME"
That 50-line script replaces days of manual setup. Every new service starts from the same baseline. Every new service has working CI, monitoring, and GitOps from day one.
The Service Template
The template repository should contain:
service-template/
├── .github/
│ └── workflows/
│ ├── ci.yaml # lint, test, build, push image
│ └── cd.yaml # update image tag in helm/values.yaml
├── Dockerfile
├── helm/
│ ├── Chart.yaml
│ ├── values.yaml # default values
│ └── templates/
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ ├── hpa.yaml
│ ├── servicemonitor.yaml
│ └── pdb.yaml
├── src/
│ └── main.ts # placeholder application
├── tests/
└── README.md
The Helm chart in the template includes readiness probes, resource limits, PodDisruptionBudgets, and a ServiceMonitor. Every service that starts from this template is production-ready by default.
When to Add Backstage
Add a service catalog (Backstage or similar) when:
- •You have 15+ services and engineers cannot discover what exists
- •You want a unified view of deployments, alerts, and documentation per service
- •You are onboarding more than 5 engineers per quarter and need searchable runbooks
Backstage setup at a minimum:
yaml# backstage/app-config.yaml app: title: Engineering Portal catalog: rules: - allow: [Component, API, Resource, Group, User, Template, System] locations: - type: github-discovery target: https://github.com/your-org rules: - allow: [Component, API] kubernetes: serviceLocatorMethod: type: multiTenant clusterLocatorMethods: - type: config clusters: - url: https://your-eks-endpoint name: production authProvider: aws techdocs: builder: local generator: runIn: local publisher: type: awsS3 awsS3: bucketName: your-techdocs-bucket region: us-east-1
Backstage is a significant investment - plan for 4–6 weeks to set it up properly with real data, not a demo install.
What Not to Do
Do not build a platform team before you have the pain. A platform team at 15 engineers is overhead. Wait until you have clear signals: DevOps tickets piling up, inconsistent service setups, slow onboarding.
Do not start with Backstage. Start with the golden path script. The catalog is only valuable when you have services to catalog.
Do not let the platform team become a gatekeeper. The goal is self-service. If engineers still need to open tickets to use the platform, it is not a platform - it is bureaucracy with a nicer UI.
The Business Case
The average developer at a 50-person startup spends 4–6 hours per week on infrastructure-adjacent tasks: setting up pipelines, debugging environment issues, getting access to things, waiting for DevOps help.
At $150K/year average engineer cost, that is $15,000–$22,500 per engineer per year in lost productivity. For 20 engineers: $300K–$450K annually.
A well-implemented golden path and IDP recovers most of that. It also makes you a more attractive employer - engineers want to work at companies where the internal tooling is good.
Seeing the signs that you need platform engineering but not sure where to start? Book a free audit - we will assess your current developer experience and scope a golden path implementation.