Platform engineering is the discipline of building the internal systems that let product engineering teams ship reliably without becoming infrastructure experts. It’s what sits between “we push code to main” and “it runs in production” — the CI/CD pipelines, Terraform modules, Kubernetes manifests, observability stacks, and deployment workflows that make the former possible.

For enterprise teams, this is whole departments and million-dollar tooling budgets. For startups, it’s usually one platform-adjacent engineer holding it together with bash scripts and prayers.

This guide is for that second category.

What problem does platform engineering solve?

As teams grow past ~5 engineers, infrastructure complexity compounds:

  • Multiple engineers making simultaneous Terraform changes → state conflicts, unreviewed drift
  • “Works on my machine” CI — no standard way to run the same pipeline locally
  • Cloud costs invisible until the bill arrives
  • On-call pager goes off with no runbooks, no dashboards, no context

Platform engineering is the systematic answer: define and automate the golden path for how your team deploys, tests, scales, and observes software. The goal is to make the right thing the easy thing.

CNCF tools for startups

The CNCF landscape is genuinely overwhelming. Here’s what’s practical for a startup:

IaC automation

Terraform / OpenTofu for resource definitions. OpenTofu is the CNCF-hosted, BSL-free fork of Terraform — use it for new projects.

Neptune (devopsfactory-io/neptune) for PR automation: plan on PR open, apply on @neptbot apply comment. Enforces apply-before-merge so infrastructure changes go through the same PR review process as application code.

Container orchestration

Kubernetes — eventually. Not at 5 engineers. If you’re shipping a SaaS product and not yet running Kubernetes, ECS or Cloud Run gives you 80% of the benefit without the operational overhead.

GitOps

Argo CD for Kubernetes config management. Declarative, auditable, rollback is a git revert. Add when you have Kubernetes.

Observability

OpenTelemetry for instrumentation (vendor-neutral traces, metrics, logs). Prometheus + Grafana if self-hosted. Cloud vendor metrics (CloudWatch, Cloud Monitoring) if managed is fine.

When does a startup need platform engineering?

Common inflection points:

  • >3 engineers touching infrastructure → You need PR-based IaC workflows (Neptune, Atlantis, or manual discipline)
  • >10 engineers deploying independently → You need a deployment platform with self-service capabilities
  • Incidents with unclear blast radius → You need observability before you need anything else
  • “We can’t move fast because infrastructure is slow” → Platform bottleneck

The expensive mistake is waiting until pain is severe. The cheap mistake is building a platform before you have problems.

What we’re building

At devopsfactory.io, we’re building open source tools targeting the inflection points above:

  • Neptune — IaC PR automation for teams already using Terraform/OpenTofu
  • jit-runners — On-demand GitHub Actions self-hosted runners on EC2 Spot instances

All are MIT licensed, built in Go, and designed to integrate with GitHub Actions rather than replace it.

Follow our GitHub organization to track what we’re building next.