Atmora Tech

Cloud & Platform

A platform your engineers
choose to use

Internal platforms fail when they are built as a mandate. We build them as products: a small number of paved paths that are genuinely faster than the alternative, an escape hatch for the cases they miss, and a team that answers support requests.

Overview

An internal platform with golden paths, run as a product with users and a roadmap.

The test for an internal developer platform is simple. If teams route around it, it has failed, however good the architecture underneath happens to be. That means the platform has to be measurably faster than doing it yourself for the common cases, and it has to let people out when their case is not common. Mandating adoption hides the failure rather than fixing it.

We usually start with two or three golden paths rather than a catalogue: a stateless HTTP service, a scheduled job, and one stateful shape appropriate to your estate. Each path takes an engineer from an empty repository to a running production service, with logging, alerting, a database and a deployment pipeline already wired, in under an hour.

Underneath, the interface matters more than the implementation. Backstage, a CLI, a set of Terraform modules or a pull request template are all viable front doors. What breaks platforms is exposing raw Kubernetes manifests to product engineers and calling it self-service. We hide what should be hidden and document the seams where we could not.

47 min
from empty repository to production service on a golden path
73%
of new services on a paved path within two quarters, no mandate
2.4 FTE
platform team supporting 180 engineers at steady state

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • Platform product definition

    User research with the engineers who will use it, a prioritised roadmap, and success measures such as time to first deployment. The platform gets a product owner, not only a technical lead.

  • Golden path implementation

    Two to four templated service shapes covering the common cases, each producing a running service with pipeline, observability, secrets and a database attached from the very first commit.

  • Developer portal and catalogue

    Backstage or an equivalent populated with ownership, dependencies, on-call rota and runbook links, kept accurate by generating it from code rather than by asking teams to update entries.

  • Infrastructure self-service

    Crossplane or Terraform modules exposed behind a request a product engineer can complete alone, with policy enforced automatically instead of through an architecture review board.

  • Multi-tenancy and isolation

    Namespace strategy, network policy, resource quotas and per-tenant cost attribution, designed so that one team's incident does not quietly become everybody else's incident.

  • Platform operations and support

    A support rota, a published SLO for the platform itself, a deprecation policy with migration windows, and release notes. Internal products need the same discipline as external ones.

Deliverables

What you get

  • Platform roadmap with adoption and time-to-deploy targets
  • Golden path templates generating pipeline, observability and infrastructure
  • Backstage instance with the catalogue populated from repository metadata
  • Self-service infrastructure modules with policy checks in the pipeline
  • Platform SLOs, support rota and deprecation policy
  • Migration guide and paired sessions for the first adopting teams

Stack

What we build it with

  • Backstage
  • Crossplane
  • Kubernetes
  • Argo CD
  • Terraform
  • Kyverno
  • Helm
  • GitHub Actions
  • External Secrets Operator
  • Grafana
  • OpenTelemetry
  • Dagger

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Interview the users

    Ten to fifteen product engineers, asked how they set up their last service and where they lost time. The answers rarely match what the platform team assumes.

  2. Pick two paths

    We implement the two most common service shapes completely. A broad catalogue built up front ages badly, and nobody adopts a path that is only half finished.

  3. Pilot with a real team

    One product team ships a genuine service on the path while we sit in their support channel. Their friction log becomes the platform backlog.

  4. Open it up

    Adoption by choice, tracked weekly. If teams are not adopting, the answer is a change to the platform, not an engineering-wide mandate from a director.

  5. Establish the platform team

    Support rota, roadmap cadence, deprecation policy and a funding model, so the platform is still maintained long after the initial build finishes.

When this is the wrong engagement

If you have one product, one team and one deployment target, a platform is simply a layer of indirection between you and the thing you are actually trying to build.

FAQ

Questions we get asked

How large does an engineering organisation need to be?

Below roughly 40 engineers, a shared set of Terraform modules and a good README does the same job for a fraction of the cost. Platform engineering starts paying back when the number of services outgrows the number of people who remember how each one was set up.

Backstage or a commercial portal?

Backstage if you have a team that can own a React codebase and want the catalogue model extended to your own entities. A commercial portal if you want it running next month and can live with its data model. Either way the portal matters least; the golden paths carry the value.

What if teams refuse to adopt it?

Then it is not yet faster than their current approach, and mandating it turns a product problem into a political one. We treat non-adoption as the primary signal, interview the holdouts and fix the specific friction. Adoption by choice starts slower and lasts far longer.

How should we fund a platform team?

As a permanent product team with its own headcount, not as a project with an end date. Platforms funded as projects decay within about 18 months: deprecations stop happening, modules drift from the provider APIs, and teams quietly go back to building their own.

Related

More in Cloud & Platform

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project