Platform engineering

Platform Engineering for Growing SaaS Teams

What an internal platform should actually contain at 10, 30 and 50 engineers — and how to avoid building a platform nobody uses.

8 min read

Platform engineering goes wrong in two directions. Either nothing is standardised and every team reinvents deployment, or a platform team builds an abstraction so heavy that product engineers route around it. The useful middle is a paved road: one supported path that is genuinely faster than doing it yourself.

At ~10 engineers

You do not need a platform team. You need consistency: one deployment pipeline pattern, infrastructure in Terraform, and a documented way to create a new service. The goal is to avoid accumulating divergence you will have to unwind later.

At ~30 engineers

This is where the tax becomes visible. Multiple teams, multiple services, and senior engineers spending a day a week unblocking others. Here a platform is worth explicit investment: service templates, self-service environments, a standard observability bundle wired in by default, and clear ownership of the delivery path.

At ~50 engineers

The platform needs a product mindset: a roadmap, users you talk to, and adoption metrics. It also needs guardrails rather than gates — policy enforced in pipelines instead of approval queues. If your platform team is a ticket queue, it will become the bottleneck it was created to remove.

What belongs in the paved road

  • Scaffolding: create a new service with pipeline, infrastructure, dashboards and alerts already attached.
  • Environments: ephemeral or on-demand, provisioned without a ticket.
  • Delivery: one pipeline pattern, tested rollback, progressive delivery where it matters.
  • Observability by default: traces, metrics and logs wired in at scaffold time.
  • Secrets and identity: workload identity, no long-lived credentials.
  • Golden-path documentation that is shorter than the alternative path.

How to know it is working

Measure lead time for change, deploy frequency, change failure rate and time to restore — plus one platform-specific metric: time from repository creation to first production deploy. If those are not improving, the platform is a cost centre regardless of how elegant it is.

The adoption rule

Never mandate adoption before the paved road is faster. Mandates applied to an unfinished platform produce compliance without trust, and the teams you most need on board — the ones shipping hardest — will be the ones who resent it.

Want this assessed against your own environment?

The Aspiron Infrastructure Review applies exactly this analysis to your cloud, delivery pipeline and cost — 2 weeks · fixed scope · no long-term commitment.

Book an Infrastructure Review