Platform & Cloud Infrastructure

Deploys should be the least interesting part of the week

The layer underneath the product: environments you can recreate from source, deploys that are boring, and enough instrumentation to diagnose production without guessing.

Why this comes up

The clearest signal that infrastructure needs work is a calendar: deployments happen on Thursday evening, because that is when someone senior can watch. The second clearest is a staging environment that nobody trusts, because it drifted from production eighteen months ago and no one can now say how.

Both come from the same root. The environment exists as a sequence of things people did, rather than as something described in a file. It cannot be recreated, so it cannot be tested against, so every deploy carries risk that has to be managed by attention rather than by process. Teams then compensate with ceremony — freeze windows, manual checklists, a rollback plan that has never been rehearsed.

The work here is unglamorous and it compounds. Describe the infrastructure in code, make the pipeline reproducible, put in enough instrumentation that a production question has an answer rather than a theory. Done properly, the result is boring: deploys happen on a Tuesday morning, several times, and nobody watches.

What you get

Deliverables, not adjectives

Environments recreated from source

Networking, compute, databases, secrets management and IAM described in Terraform or the platform-native equivalent, so staging is production with different sizing rather than a distant relative. A destroyed environment should be rebuildable, and we test that claim rather than asserting it.

A pipeline that produces the same artefact twice

Build once, promote the same image through environments, with staged rollout and a rehearsed rollback. Migrations handled as their own step with a forward path, because 'roll back the deploy' rarely means 'roll back the schema'.

Observability aimed at questions, not dashboards

Structured logs with request correlation, traces across service boundaries, and alerts tied to user-visible symptoms rather than to CPU. The test is whether an engineer at 2am can find the cause without reading source code — a dashboard that looks impressive and answers nothing is worse than none.

Cost visibility and resource limits

Spend attributed to services and environments, plus the limits that stop a runaway job becoming an invoice. Cloud bills are usually a handful of decisions, and they are much easier to change once they are visible.

Scope at a glance

Infrastructure as code on AWS, Azure or GCP
CI/CD with reproducible builds and staged rollouts
Container orchestration, autoscaling and resource limits
Structured logging, tracing, alerting and cost visibility

What we reach for

Defaults rather than rules. Each one gets argued against on a project where it does not fit — the reasoning matters more than the tool.

Provisioning: Terraform where the estate spans providers; native tooling where it genuinely does not.
Runtime: Containers on managed orchestration, or serverless where the workload is genuinely bursty and stateless.
Pipeline: GitHub Actions or GitLab CI, with the build logic kept out of provider-specific YAML.
Telemetry: OpenTelemetry for instrumentation, so the backend that stores it stays a commercial decision.

How it runs

Durations are ranges because a single confident number this early is a guess in a suit.

Engagement shape

Fixed-scope platform build, or a retainer where an existing estate needs steady improvement.

Typical duration

Six to twelve weeks for a first reproducible environment and pipeline.

Starts with

An inventory of what runs where and who can change it — which is frequently the first time that has been written down.

When this is the wrong thing to buy

We would rather lose the enquiry here than three months in. If you recognise your situation below, say so on the first call and we will tell you what we would do instead.

Adopting Kubernetes because it is expected. If three containers and a managed database will do, we will say so and decline the larger build.
A migration to a new provider with no reason beyond credits. The switching cost usually exceeds the discount.
Teams without anyone who will own the platform afterwards. We can build it and document it, but infrastructure with no owner decays.

Questions we get asked

We are on one cloud already. Do you work with that?

Yes. AWS, Azure and GCP all do this job well, and the differences matter far less than whether your setup is reproducible. We would rather improve what you are on than argue for a migration you did not ask for.

Do we need Kubernetes?

Often not. Kubernetes is a reasonable answer to real problems — many services, complex scheduling, teams needing isolation — and an expensive answer to none of those. We size the platform to the team that will operate it after we leave, which is usually smaller than the one that would enjoy running a cluster.

Can you do this without stopping feature work?

That is the normal case. Infrastructure work runs alongside product delivery, sequenced so each change is independently safe. It also tends to be the only way it gets funded, so we scope it that way by default.

What happens when something breaks after handover?

You get runbooks for the failure modes we know about, alerting that points at the right one, and the option of a retainer. If you would rather run it entirely in-house, the handover includes working sessions rather than a document dump.

Talk to us about platform & cloud infrastructure

Send the problem rather than a feature list. You will get an approach, a range and an honest view of what it takes — including whether you need this at all.

Book a 15-min strategy call