The first call
Twenty minutes with the engineer who would do the work. No account manager and no pre-sales.
Company
Senior cloud and platform engineering, delivered into your own repositories.
InfraEdge is a UK cloud and platform engineering practice, established in 2023. We take on defined projects for technology companies whose product has grown faster than the infrastructure behind it, and we leave the result with your engineers: in your repositories, documented, and yours to run.
- Established
- 2023, in the UK
- Deepest on
- AWS
- Engagements
- Scoped packages with a written completion test
- In the open
- Free tools, published at github.com/infraedgecloud-tools
What we do
We work on the layer between your application and the cloud provider: accounts and identity, infrastructure as code, delivery pipelines, security controls, recovery, observability and cost. AWS is where we go deepest. The same engineering carries to Azure, Google Cloud and Kubernetes, and to whichever infrastructure-as-code and CI/CD tooling you already run.
Most engagements follow one path. EdgeAssess establishes where the estate stands, from evidence. EdgeResolve fixes what matters, as code in your repository. EdgeAssure keeps it from drifting back. Investors use EdgeSignal for an independent view of infrastructure risk before a deal.
Where the experience comes from
Production work: multi-account estates, landing zones and identity, infrastructure code other engineers have to maintain, Kubernetes that somebody is on call for, pipelines that span teams and toolchains, and incidents, followed by the work of making sure the same failure cannot happen twice.
That is why we judge an architecture by whether your engineers can deploy safely, see what changed six months later, and recover when something fails, rather than by how it looks on a diagram.
How automation fits
We use automation, deterministic checks and AI-assisted tooling where they make the work faster and more consistent: collecting configuration, running the same controls across every account, drafting repetitive code, and re-checking each fix after it is applied.
Engineers do what requires judgement: deciding what matters for your business, designing the change, reading every line before it reaches you, and explaining it. No tool of ours approves a change or applies one to your production; every decision and every change is reviewable and attributable to a named person.
What you are left with
Code, tests, documentation and runbooks in your repository, and a team that can operate them without us. Clients are welcome to keep working with us. None of them have to.
Who does the work
A senior engineer leads every engagement, from the first call to the handover.
The engineer you speak to first is the one who assesses the estate, writes the changes and hands the work over. Nobody sells an engagement that somebody else then has to deliver.
The findings walkthrough
The same engineer takes your team through what was found, with the evidence, before anything is changed.
The pull requests
The engineer writes each change and answers your reviewer. Your named approver decides.
The handover
Runbooks, the decision record and the backlog, handed over to whoever will run it, with pairing agreed in the scope.
What protects the work if that engineer becomes unavailable is set out under continuity, next.
Continuity
How your project is protected.
If the engineer leading your work becomes unavailable, or you stop part-way, you can carry on from the written record: with us, with your own team or with another supplier.
Everything is in your repository
Work is delivered as code in your repository and reviewed through your process, with the runbooks and the decision record beside it. Nothing depends on a system of ours.
Work is scoped in bounded packages
Each package has a written completion test, so the work in progress at any time is small and its state is documented. If an engagement paused, you would hold everything merged so far and a written record of what was outstanding.
Dates are confirmed, not assumed
A start date is agreed with the scope. A delivery date is confirmed in writing once access is in place, not before. If a date you need looks unachievable, we say so at scoping.
How we work
Six commitments on every engagement.
What you can hold us to, whatever the size of the work.
Evidence before opinion
Assessments start from the estate itself: configuration, deployment paths, permissions, telemetry and cost. Every finding cites its evidence, and anything we could not check is stated.
Your tools and your process
We work in the cloud, infrastructure-as-code and CI/CD tooling you already run, and changes go through your own review. We do not move you to a tool because we prefer it.
You keep every decision
A named person on your side approves each change before it is applied. We do not hold production authority.
Everything written down
Decisions, runbooks and a ranked backlog of what we chose not to do are delivered with the code. If it only exists in someone’s head, it is not finished.
Simple over clever
A removed manual step is better than an added tool. We build infrastructure your team can understand and change.
Straight answers
If your own engineers should do the work, or another supplier is a better fit, we say so on the first call.
Appointment
How an engagement is agreed.
The commercial steps, separate from the technical method. Nothing starts before the scope is signed.
- 01 An initial discussionTwenty minutes, no charge, nothing to prepare, with the engineer who would do the work. What you are running, what prompted the call, and whether this is work we would do well. If your own engineers should do it, we say so here.
- 02 Fit and inputs confirmedWhat the work needs from you: the access, the reviewer, the decisions, the environments. This is where an engagement usually turns out larger or smaller than first described.
- 03 A written scope and a priceWithin 24 hours of the call. It names the package, what done means, what you supply and what is excluded. Nothing is priced on the call itself, because the number depends on the estate.
- 04 Delivery, with your decisions in itWork arrives as pull requests in your repository and is reviewed by your people. Where a decision belongs to you, it waits for you.
- 05 Acceptance and handoverThe package closes against the completion test agreed in the scope. You keep the code, the tests, the runbooks and a ranked backlog of what we did not do.
If procurement needs a supplier questionnaire, a security review or a data-processing agreement first, say so early. The security page is written for that review.
Request a 20-minute triage call
Twenty minutes, no charge, with the engineer who would do the work. 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.