Cloud & Platform
Infrastructure your on-call
engineer can reason about
Infrastructure as code, blue-green deploys and SLOs with consequences attached. Runbooks written so somebody can follow them at three in the morning without paging us.
Capabilities
What this covers
Cloud & Platform
Cloud Solutions
Landing zones, account structure and cost guardrails, designed before workload one.
Cloud & Platform
Cloud Migration
Wave-planned migration of running systems, with a rollback path we have actually tested.
Cloud & Platform
AWS Services
AWS engineering from Organizations and Control Tower down to Graviton instance sizing.
Cloud & Platform
Azure Services
Azure for organisations with Active Directory, auditors and an on-premises estate to keep.
Cloud & Platform
Google Cloud Services
Google Cloud engineering centred on BigQuery, GKE and the data that justifies the move.
Cloud & Platform
DevOps
Delivery pipelines, release engineering and incident practice, measured by DORA metrics.
Cloud & Platform
Platform Engineering
An internal platform with golden paths, run as a product with users and a roadmap.
Quality & Support
Cybersecurity
Threat modelling, identity hardening and detection engineering that finds real paths in.
How we work
The delivery model
Discovery and technical due diligence
2–3 weeksTwo engineers and a delivery lead go into your codebase, database and incident history. We read the schema, run a dependency and CVE inventory, sit with the people who actually use the system, and measure what is slow rather than accept what is reported as slow. Output is a written architecture assessment, a risk register with named owners, and a costed delivery sequence carrying a stated ±25% confidence band. Fixed fee, and the documents are yours whether or not the engagement continues.
Architecture and delivery plan
1–2 weeksWe record the decisions as architecture decision records: service boundaries, data ownership, sync versus event-driven integration, the consistency model, and what we deliberately are not building. Non-functional targets get numbers — p95 latency, concurrent users, recovery point and recovery time objectives, retention windows. You approve the plan, the team roster by name, and the definition of done before any production code is written.
Foundation sprint and first production deploy
3 weeksInfrastructure as Terraform in your cloud account, repositories in your GitHub organisation, CI with unit tests, SAST and container scanning, and Argo CD promotion into staging and production. Before feature work starts we put a thin but real slice of the system into production behind a feature flag, with dashboards, alerts and an on-call runbook attached. That deployment happens in week three and is the point at which the pipeline stops being a promise.
Iterative build
8–20 weeksTwo-week sprints, trunk-based development, deployment to production on merge behind flags. Each sprint ends with a working increment on your infrastructure, not a demo environment. You get a burn-up against the agreed scope, the DORA four metrics for the team, and an explicit list of what moved out of scope and why. The first release to real users typically lands between weeks 10 and 16, depending on integration surface.
Hardening, performance and security testing
3–4 weeksLoad testing to twice the agreed peak, with results published as latency percentiles rather than averages. Failure injection on the dependencies that matter — database failover, broker partition, third-party timeout. A third-party penetration test against the release candidate, with every high and critical finding closed before cutover and mediums scheduled with dates. Backup restore is rehearsed in full, timed, and written into the runbook.
Cutover, hypercare and handover
4–6 weeks, then ongoingMigration runs as a rehearsed sequence with a rollback path measured in minutes, usually strangler-fig routing so the legacy system stays live and reversible. Four weeks of hypercare with our engineers on your on-call rota, then a structured handover: runbooks, architecture diagrams that match the deployed system, recorded walkthroughs and paired shifts with your team. Where you keep us on, the same named engineers move to a run-and-evolve cadence.
Reading
Related writing
10 min read
SSRF is an identity problem, not a network problem
A URL allowlist on Northwind's webhook feature was defeated by DNS rebinding in under a minute. Validating hostnames cannot work; validating the socket can. And the deeper fix is internal services that refuse unauthenticated callers.
9 min read
Rotating database credentials without a maintenance window
Aldridge Risk had database passwords three years old because rotation meant downtime. The two-role pattern, why connection pools make rotation hard, and how to time the revoke so it is safe rather than hopeful.
11 min read
CPU limits were costing us latency and money at the same time
Corvus Logistics ran 96 nodes for a workload that fits on 60. The throttling metric nobody was watching explained both the node count and a 810ms p99. What CFS quota does, and how to set requests from evidence.

