Unknown state
- Manual console changes
- Configuration spread across multiple places
- Current state difficult to explain
Hero photograph: office collaboration by Tim van der Kuip on Unsplash.
AWS-led platform and DevOps engineering · UK
Production-ready infrastructure, engineered and handed over.
A small team of senior platform engineers, for growing product companies without enough senior platform capacity of their own. We find out where your estate stands, fix what matters as code in your repository, and keep it from drifting back.
AWSAzureGoogle CloudKubernetesTerraformTerragruntHelmArgo CDGitHub ActionsAzure DevOpsDatadogPrometheusGrafana+ more
- Landing zones
- Active Directory migrations
- Kubernetes, ECS, Terraform, Terragrunt, Helm, Argo CD
- GitHub Actions and Azure DevOps
From cloud sprawl to control
Your tools aren't the problem.
Fragmented ownership is.
Your estate already has monitoring, CI/CD, Terraform, IAM and security tooling. The trouble starts when changes happen in different places, ownership blurs, and nobody can confidently explain the current state.
InfraEdge turns that sprawl into an operating model your engineers can trust.
A controlled change model
Infrastructure change becomes reviewable,
reproducible and auditable.
Git becomes the record of intended infrastructure change — backed by Infrastructure as Code, CI/CD and review or approval where required.
Current estate
- Terraform
- CI/CD
- Datadog
- Kubernetes
- AWS
Multiple tools. Multiple control points. Unclear ownership.
InfraEdge engineering layer
- EdgeReady
- EdgeResolve
- EdgeAssure
- EdgeSignal
- Discover
- Define
- Engineer
- Assure
Controlled change
-
Git / IaCCI/CD
-
Review / approval
Known intent · Reviewable change · Clear ownership
-
01
Understand what exists
Map the accounts, infrastructure, pipelines, identity and operational tooling already in place.
-
02
Agree what good looks like
Define architecture, ownership, standards, guardrails and priorities before engineering begins.
-
03
Engineer change through code
Infrastructure changes become reproducible through IaC, Git and CI/CD rather than undocumented console actions.
-
04
Review, deploy and operate
Appropriate changes are reviewed, deployed through controlled workflows and left with clear ownership.
Where most teams start
01 / 8
An estate nobody planned, turned into one you can reason about.
Nobody decided to run production this way. It happened while the team shipped features: manual console changes, no documentation, and a risk position nobody can state out loud.
From organic growth to engineered control
Turn an estate nobody planned
into one your team can reason about.
Before — organic estate
InfraEdge
After — engineered estate
-
State
Defined state
- Infrastructure represented as code
- Accounts and environments documented
- Intended state is visible and reviewable
-
Change
Uncontrolled change
- Ad-hoc deployments
- No consistent repeatable process
- Limited audit trail
Controlled change
- Git-based change workflow
- CI/CD deployment
- Review and approval where required
- Changes traceable to commits
-
Assurance
Unclear assurance
- Risk assessed inconsistently
- Monitoring coverage unclear
- Backup controls not always verified
- Drift grows unnoticed
Continuous assurance
- Monitoring and alerting defined
- Risks explicitly assessed
- Backups and controls verified
- Drift identified and remediated
Known state. Reviewed change. Clear ownership.
Infrastructure is defined as code where appropriate, changes move through controlled workflows, and engineers can understand how the estate is meant to operate.
The gap we exist to cover
Production needs more than a founder-managed account long before it needs a platform team.
1 of 5 · scroll to follow the curve
- RequiredCost and effort production actually demands.
- AppliedWhat a founder-managed account can give it.
- The gapUnpaid effort — then Terraform, runbooks and a hire-ready backlog.
- 01You ship
One AWS account. Founder keys. Everything is manual because everything is small, and that is the correct trade at this stage.
- 02It gets real
Customers, spend and uptime start to matter. Production quietly becomes load-bearing while nobody is looking after it full time.
- 03The gap opens
Too early to justify a platform org. Too late for the estate to live in one person’s head. This is the expensive part, and it is where most teams sit.
- 04We cover the gap
Senior platform engineering, capped and scoped. The estate gets documented, hardened and reproducible while your engineers keep shipping product.
- 05A hire walks in
When you do hire, they inherit Terraform, runbooks and a backlog instead of folklore. They are useful in week one, not month four.
Not sure where you are on that curve?
Seven questions, and we will tell you where to start.
Where the estate is today, what is creating the pressure, and who owns the platform. Two minutes, and you get a written recommendation with the reasoning behind it.
What we sell
02 / 8
Three stages in sequence, and one lens for investors.
Find out where the estate stands. Fix what matters. Keep it from drifting back. EdgeSignal answers the same questions for an investor. Where you start depends on the estate.
- 01 EdgeReady Where does the estate actually stand? A scored assessment and a backlog in priority order, every finding citing evidence you can open.
- 02 EdgeResolve Fix what matters, as code. Terraform in your repository, reviewed in pull requests and applied behind an approval you gave.
- 03 EdgeAssure Does it stay fixed? Drift, posture, backups, access and cost tracked over time, reviewed by an engineer each month.
and then assess again Remediation nobody re-checks is most of the way back within two quarters. That is the whole reason the third product exists.
What you keep
03 / 8
A repository, not a PDF and a login to our portal.
Not a document about your infrastructure — your infrastructure, described in code that runs, with the process around it tested, in your repository.
your-org/infra
main · yours
- infra/ Your repository. Ours is not in the loop.
- terraform/ Every account described in modules you can read
- accounts/ management · identity · log-archive · staging · prod
- modules/ Written to be changed by your team, not admired
- .github/workflows/ plan on pull request, apply behind an approval
- docs/ Runbooks and decision records, versioned with the code
- runbooks/ Written for whoever holds the pager at 03:00
- decisions/ Why, not only what — one file per decision
- inventory/ Every account, workload and owner, regenerated on demand
- BACKLOG.md What we did not do, ranked, with the reasoning
History of the engagement
5 of 61 commits
- a7f21c4 docs: add the restore runbook, with the timing we measured
- 3f9ac21 feat: separate staging and production accounts
- 91be0d7 fix: scope the deploy role trust policy (IAM-014)
- 5c40a18 feat: org trail into a log archive account
- 0e8d33b chore: import the estate into Terraform state
Every change we made is a commit with a message, a plan hash and a named approver. You can reconstruct the whole engagement from git log without calling us — which is the point.
Not just code in Git — identity, recovery and automation that keep running in your accounts after we leave.
Permission-set policies
Scoped to the roles you actually have
- PlatformReadRead-only across the estate
- PlatformDeployCI through OIDC — no stored keys
- PlatformBreakGlassTime-boxed, alerts when used
- PlatformAuditAuditor view, no shared login
Backup and DR plan
RPO and RTO per tier, rehearsed
- DatabasesPoint-in-time restore, timed
- Object storageVersioned, deletion-protected
- Backup isolationOff the workload credential path
- Infrastructure stateTerraform state locked
Repeatable jobs and schedulers
Running in your accounts, not ours
- nightly-planDrift caught before it is a finding
- dev-schedulerNon-prod off outside hours
- restore-drillRestore proof on a schedule
- expiry-watchCerts and secrets before expiry
A working, tested process in your cloud — not a PDF and a login to somebody's portal. Everything above is a file in the repository beside it, not a separate system you have to trust us to keep running.
-
01
Repeatable jobs
Scheduled, versioned, not a cron entry on someone’s laptop
-
02
Environment schedulers
Non-production stopped outside working hours
-
03
Golden paths
A template for the next service, not a blank page
-
04
Self-service
A pull request gets an environment without a ticket
See the deliverable first
Read a real EdgeReady report
The complete deliverable, unabridged: maturity across six pillars, fourteen worked findings with the evidence behind each, a cost baseline and a 30/60/90 plan. The subject company is invented; the structure and the rigour are exactly what you would receive.
Name and work email, then it lands in your inbox. Two fields, and we do not run a nurture sequence off them.
The cost of leaving it
04 / 8
Doing this early is not tidiness. It compounds.
Every month an estate runs without structure, the cost of adding it goes up — and not linearly. The clean-up eventually happens against a production system with real customers on it.
Done early, on your schedule
Done late, against someone else's deadline
Illustrative, not measured. The shape is the claim, not the numbers — ask us on the call what we have actually measured.
And when you do hire
05 / 8
We help you make the platform hire, and we do not disappear the day they start.
The worst version of hiring is a good engineer spending their first quarter reverse-engineering an account nobody documented. We scope the role, help you sift and interview, and hand over an estate worth inheriting.
-
Before the hire
Scope, sift, interview- Write the role against the real estate
- Second pair of ears on the technical stage
- No placement fee
-
During onboarding
A documented estate- Terraform they can read on day one
- Runbooks, not folklore
- We stay alongside at reduced capacity
-
After
Useful in week one- Inherits Terraform, runbooks, pipelines
- A backlog, ranked, with reasoning
- Not week four
We are not a recruitment agency — there is no placement fee, so no incentive to push a hire you are not ready for.
Some of our past work
06 / 8
Anonymised scenarios from prior delivery.
Described by technical shape rather than client name — the interesting part is the constraint and what it took to move it.
Platform
A founder-managed account became a platform
Most of the estate had been built by hand in the console. Mapped, split into accounts, moved into Terraform, and handed to the internal team.
Migration
Years of hand-built AWS, imported rather than rebuilt
VPCs, RDS, S3 and IAM roles brought under Terraform state without a risky start-again migration.
Resilience
Backups that had never actually been restored
Critical workloads mapped, RTO and RPO agreed, controlled restore tests run, and the timings written down.
Who this fits
07 / 8
Startups through medium enterprise, running real production infrastructure.
The common thread is not size or which cloud, but that production became load-bearing faster than the structure around it.
Production already running, on AWS, Azure or GCP
A named technical owner to work with
Something specific prompting the call
Willing to have changes reviewed and approved
Who you actually get
The person on the call is the person doing the work.
A small team from SRE, DevOps, infrastructure and development backgrounds. We use automation and AI-assisted tooling properly, which is how a team this size carries real ownership without a larger firm's overhead. It is how the work gets done, not the reason to buy.
For investors
08 / 8
Assessing a cloud estate before you write the cheque?
Infrastructure diligence for venture capital, growth equity and private equity, and a consistent risk view across a portfolio afterwards. Findings arrive translated into investment impact, growth constraint and remediation effort. It informs the decision; it is not investment advice.
Book a 20-minute triage call
Twenty minutes, no charge. We work out what would actually help — which is sometimes us and sometimes not. Nothing is priced on the call; if there is work worth doing, a written scope and a price reach you within 24 hours.