The estate becomes reproducible
Resources that existed only because somebody clicked a button eighteen months ago become code you can read, review and rebuild. The console stops being the source of truth.
EdgeResolve · remediation and platform build
Fix what matters, delivered as code in your repository.
This is the work itself — one named production problem, a full production baseline, or as long as there is a backlog worth clearing. The shape does not change: every change arrives as a pull request against code in your repository, passes policy and security checks, and is applied only after a named person approves a specific saved plan.
Start with visibility and readiness
Continuous improvement and confidence
What changes for you
Changes stop being frightening
A deployment path with a plan, a review and an approver is not bureaucracy. It is what makes it possible to change production on a Friday without anyone holding their breath.
Blast radius shrinks
Separate accounts, centralised identity and preventive guardrails mean a mistake in staging has no path into production except the ones deliberately created — and those are enumerated and tested rather than assumed.
Your team can carry it
Every piece of work lands with the reasoning written down. The measure is whether your engineers could make the next change without us, and that is what gets built.
What you are left holding
Everything below lands in your repository and your accounts. If you stop working with us, none of it stops working.
- Terraform in your repository, structured into modules your team can extend rather than a single flat file nobody wants to touch.
- A working CI/CD path from Git to AWS: plans on pull requests, policy and security checks, environment approvals and controlled production applies.
- A multi-account structure with centralised identity, guardrails and centralised logging.
- Backups with a documented, timed and actually-performed restore — not a backup policy nobody has exercised.
- Personalised permission-set policies scoped to the roles your team really has, not a copy of an AWS example policy.
- Runbooks and a decision record for anything non-obvious, so the next engineer inherits reasoning rather than archaeology.
- A remaining backlog, honestly sized, including the things we recommended against doing.
What is included
- Remediation of findings from an EdgeReady assessment, or from your own audit.
- A production baseline: accounts, identity, logging, backups, network and Terraform.
- One named production problem, diagnosed and fixed properly rather than patched.
- Migration of existing hand-built resources into Terraform state, without rebuilding the estate.
- Deployment pipelines with OIDC rather than long-lived credentials.
- Repeatable platform work: scheduled jobs, environment schedulers that shut down what is not in use, and self-service paths for your developers.
- A backup and disaster recovery plan with tested recovery timings.
- Written handover, and as much or as little pairing with your team as you want.
What is not
- Application code. We work on the platform your application runs on, not inside it.
- Production authority for us on an ongoing basis. Every apply ends at a person on your side.
- On-call or incident response cover. That is a different commitment and we do not pretend otherwise.
- A fixed price before discovery. Anyone quoting a migration price before seeing the estate is guessing.
- Kubernetes as a default answer. If you are already running it we will work with it; we will not migrate you onto it to make ourselves useful.
The exclusions are the same size as the inclusions on purpose.
What gets worked on
How every change reaches production
One route, every time, ending at a person. There is no side door for urgent changes, because the urgent ones are exactly the ones that go wrong.
Where it ends up
A repository, not a slide deck
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.
Where this has been done before
- A founder-managed AWS account, turned into a platform the team could inherit
- A brownfield AWS estate, imported into Terraform without a rebuild
- One Azure subscription, redesigned into a management group hierarchy
- A safe path from a Git commit to a production Azure change
All eleven anonymised engagements
Questions this answers
Who actually applies changes to production?
Someone on your side, every time. A change arrives as a pull request, passes policy and security checks, and is applied only after a named person approves a specific saved plan. We hold no ongoing production authority.
Do we own the code at the end?
Yes. The Terraform lives in your repository, structured into modules your team can extend rather than one flat file nobody wants to touch.
Will you work inside our application?
No. We work on the platform your application runs on, not in your application code — where the estate ends and your product begins.
Will you move us onto Kubernetes?
If you are already running it we will work with it. It is not a default answer, and we will not migrate you onto it to justify an engagement.
We have resources nobody built in code. Do we have to start again?
No. Hand-built resources are migrated into Terraform state without rebuilding the estate — the console stops being the source of truth without an outage to get there.
Can you quote a fixed price before you start?
Not before discovery — anyone quoting a migration price before seeing the estate is guessing. Work is scoped in blocks and reviewed at the end of each one.
Is EdgeResolve the right shape?
Twenty minutes on a call will tell you, and will tell us. If a different product fits better — or what you need is not on this list at all — say so. Nothing is priced on the call; a written scope follows within 24 hours.