Terraform your team can read six months later
We write modules, not monoliths — composable, versioned, documented, and tested in CI like any other code. Crucially, they live in your repositories from the first commit, so nothing about the platform depends on us still being here.
- Module library covering networking, identity, data stores and workload patterns
- Remote state with locking, per-environment workspaces and drift detection
- Policy-as-code in the pipeline: tflint, Checkov or OPA, plus a cost guard
- Import and refactor of existing click-ops resources, without a big-bang rewrite
- Documented upgrade path when a provider or module version moves
On the "rewrite everything" temptation
We import what exists before we improve it. A greenfield rewrite parallel to a running estate is where consultancies burn six months and hand back two systems instead of one.
Deploys that are boring on purpose
The goal is not deployment frequency for its own sake. It is that a change reaching production is small enough, observable enough and reversible enough that nobody needs to be brave.
Pipeline design
GitHub Actions, GitLab CI or CodePipeline — whichever you already use. Build once, promote the same artefact, no rebuild-per-environment.
Progressive delivery
Blue/green and canary with automated rollback on SLO breach, so the pipeline decides rather than a human under pressure at 6pm on a Friday.
Supply chain
Signed artefacts, SBOM generation, dependency and image scanning as a gate rather than a report nobody reads.
Secrets
Secrets Manager or Parameter Store with rotation, OIDC federation from CI so there are no static cloud credentials in your pipeline.
Environments
Ephemeral preview environments per pull request, torn down automatically — including the cost, which is the part usually forgotten.
Release governance
Change records generated from the pipeline itself, so audit evidence is a by-product of deploying rather than a separate chore.
| Platform concern | What we deploy |
|---|---|
| Cluster lifecycle | EKS with managed node groups and Karpenter, version upgrade runbook |
| Ingress & traffic | AWS Load Balancer Controller, external-dns, cert-manager |
| Identity | IRSA / Pod Identity, no node-level credentials |
| Secrets | External Secrets Operator backed by Secrets Manager |
| Policy | Kyverno or OPA Gatekeeper, admission control in enforce mode |
| Scaling & cost | Karpenter consolidation, Spot where safe, per-namespace cost visibility |
| Delivery | Argo CD or Flux, GitOps with environment promotion |
| Resilience | PodDisruptionBudgets, topology spread, tested node drain |
Amazon EKS, built to be operated
Standing up a cluster takes an afternoon. Running one for three years through version upgrades, CVE churn, noisy-neighbour incidents and a cost review is the actual job, and it is what we design for.
We also say no to Kubernetes regularly. If you run six services with modest scaling needs, ECS Fargate or Lambda will cost you less in money and far less in attention.
Instrumentation that answers questions you have at 2am
Most observability spend goes on data nobody queries. We start from the questions — what is broken, for whom, since when, and what changed — and instrument backwards from there.
- SLOs defined with the business, error budgets that actually gate releases
- OpenTelemetry instrumentation so you are not locked to one vendor's agent
- CloudWatch, Grafana, Datadog or New Relic — we work with what you have
- Log retention tiering, because 400 days of debug logs is a cost problem
- Dashboards designed for incidents, not for screenshots in a status report
The part that decides whether any of it worked
Platform engagements do not usually fail on technology. They fail because the people expected to use the platform were never involved in shaping it.
Start from a real workload
We take one of your actual services through the new path end to end before generalising. Reference implementations built on hypothetical services are always subtly wrong.
Pair, don't hand over
Your engineers build the second and third workload with us alongside. Knowledge transfer as an activity at the end of a project does not work and never has.
Measure adoption honestly
What percentage of deployments go through the golden path? If it is falling, the path has a problem — we fix the path rather than mandating compliance.
Leave documentation that survives
Written for the engineer who joins in eighteen months, in your repository, reviewed like code. Not a slide deck in someone's downloads folder.
Platform questions
We have Terraform already, but it is a mess. Where do you start?
With a state and dependency audit, then incremental refactoring
behind module boundaries — never a rewrite. The first target is usually making
plan trustworthy again, because a plan nobody believes means every change
becomes a manual verification exercise.
Do you replace our engineers?
No. We are most useful building the foundations your team will extend, or taking the operational load so your engineers can work on product. If a proposal involves us permanently owning something only your team understands, that is a bad proposal.
Should we be on Kubernetes?
Probably not, unless you have workload diversity, real scaling needs or a team that wants to own it. ECS Fargate and Lambda cover a great deal of ground at a fraction of the operational cost. We will tell you when the answer is no, including when you have already bought the training.
Can platform work run alongside managed operations?
Yes, and it usually should. Managed and Enterprise plans include a change delivery capacity for exactly this. Larger platform builds run as a separate project with the same engineers.
Make the right way the easy way
Start with a landing zone build, or a review of the platform you already have.