Service 04 of 04
Cloud, infrastructure and DevSecOps
The systems we build and connect have to run somewhere, be deployed safely, and be reachable only by the people who should reach them. We design and set up that ground: cloud environments, deployment pipelines with their checks, and access controls, all written down so your team or your IT partner can run them after us.
This line exists to support the other three. We take it on as part of an integration, a bespoke system or a hosted service, or for a business moving an existing system of that kind onto cloud hosting. We are not a general managed IT provider.
AWS or Azure. We work in both. Which one your work runs in follows the tenancy you already have, not our preference: if your IT team already operates an Azure subscription, the work goes there, and the same if it is AWS. Opening an account with the other provider gives you a second bill, a second set of identities and a second thing for your team to support, so we do it only where there is a reason, written down and agreed with you first.
One thing that is separate, said plainly: our own systems — this site, the contact form and the client working material we hold in London — run on AWS. That is our choice for our own business, and it does not decide where your work runs.
Who it is for
- A business whose integration or bespoke system runs on a single server that nobody wants to touch, with no record of how it was set up.
- A team that deploys by hand, where every release is a risk and nobody is sure what is live.
- A sponsor who has to answer "who can reach our data?" and cannot, today, in writing.
What you get
- Environments defined as code: test and live kept separate, built from scripts that can rebuild them, not from memory.
- A deployment pipeline with the checks agreed with you: automated tests, security scanning of dependencies, and an approval step before anything reaches live.
- Access controls: least-privilege access, named accounts, secrets held in a secrets store rather than in code, and a written note of who can reach what.
- Backups and a tested restore: a restore rehearsed at least once before handover, not just a backup schedule.
- Monitoring and alerting to a named person, and a runbook for the common failures.
What you don't get
- A security certification, penetration test or compliance audit. We can prepare for one and work with the firm that does it.
- A 24-hour operations desk, unless a hosted service with that support tier is agreed in the statement of work.
- Management of desktops, email, phones or office networks.
- A move to cloud for its own sake. If the system is better left where it is, the design says so.
How it runs
Read what is there. Servers, accounts, credentials, deployment steps and backups, recorded as found.
Design the target. Environments, pipeline, access model and cost estimate for the hosting, agreed in writing.
Build alongside. The new environment is built next to the old one, not in place of it.
Rehearse the cutover and the rollback, then cut over with a written yes from your decision-maker.
Hand over. Code, runbook, access list and a recorded walkthrough.
Anything that touches security or data boundaries is done by me, or by a trusted engineer I have worked with, under my review and named in the statement of work. Agents draft scripts, pipeline definitions and documentation under my review; they never hold your credentials or act on your live environment.
What we need from you
- Admin access, granted narrowly and in writing, and revoked at handover.
- A decision on whose cloud account the systems live in, and which provider. Your AWS or Azure account, or ours, named in the statement of work.
- A named person on your side to receive the access list and runbook.
What can go wrong
| What can go wrong | What we do about it |
|---|---|
| Nobody knows how the current server was set up | What we do about itRecorded as found before anything changes; the new environment is built from scripts so this does not recur |
| Hosting costs grow after go-live | What we do about itThe design carries a monthly hosting estimate; alerts are set on spend; hosting is billed to you at cost or directly by the provider |
| A credential leaks | What we do about itSecrets are kept in a secrets store, access is least-privilege, and every key can be rotated from the runbook |
| Cutover fails | What we do about itRollback is rehearsed before cutover, and the old environment stays available until the agreed clean period ends |
| Access outlives the engagement | What we do about itOur access is removed at handover and the removal is confirmed in writing |
Platforms and tools
We choose the tools from what your systems already run, not from what we prefer.
Price
| Form | Pricing basis | Price |
|---|---|---|
| Delivery of the whole (as part of a larger change, or on its own) | Pricing basisFixed price or priced milestones. Hosting and licences shown separately at cost, agreed in advance. | PriceQuoted after the solution pack |
| Hosted service (we run it) | Pricing basisSetup fee plus subscription, with service levels in the statement of work | PriceSetup from £4,000; subscription from £800 a month |
Prices exclude VAT. Terms: /engagements/.
Why the price is what it is: it is a price for the outcome, environments, a pipeline and an access model your team can run after us, not for the hours it takes. Anything touching security, credentials or your live environment is done by me or by a named trusted engineer, so most of what you pay for here is senior time. Agents I direct draft the scripts, pipeline definitions and runbooks under my review, so fewer engineering hours go into each deliverable and the work reaches go-live sooner. Hosting and licences are shown separately at cost, so you are not paying a margin on your own cloud bill. How it works, and what the agents never touch: /how-we-work/.
Every engagement is architected by me, and I'm the person you deal with.
We take on a small number of clients at a time.