Cloud services on AWS, Google Cloud and Azure

Cloud-native design and implementation, with infrastructure as code.

Serverless architectures that scale without drama and a bill you can read. Terraform or Pulumi so the infrastructure is versioned and can be rebuilt, with international data transfers documented — which is where the GDPR looks.

Who it is for

Startups outgrowing Heroku or Vercel
Businesses migrating from on-premise to cloud
Teams that need mature infrastructure as code and CI/CD

Why it ends up being needed

A cloud bill hardly ever grows because of a decision: it grows by accumulation. Someone spun up a test environment for a demo and it is still running, a database was sized for a peak from two years ago, logs are kept with no expiry. None of those is a mistake, and together they are half the invoice.

The other symptom shows up earlier: nobody knows how to rebuild the infrastructure. It was set up by clicking, whoever set it up explained the essentials out loud, and now changing a network rule is frightening because nobody knows what depends on it. The day it has to be audited, migrated or recovered from a disaster, that missing map costs weeks.

That is where having the infrastructure written down matters. Not out of orthodoxy: because a versioned file can be read, reviewed before it is applied, deployed identically to staging and production, and rolled back. And because international data transfers, the first thing a data protection audit looks at, end up documented by the code itself instead of in somebody's memory.

What I deliver

Documented architecture — C4 diagram, decision records and network diagrams.
Infrastructure as code — Modular Terraform across dev, staging and production.
CI/CD — GitHub Actions or GitLab CI, with canary deployments.
Observability — Logs, traces, metrics and alerts.
Cost optimisation — A monthly analysis of your spend, with recommendations.
Backups and tested recovery — Automatic backups and a rehearsed restore, with its time measured.

What is included

The architecture designed
Migration and go-live
Your spend brought down
Documentation and handover

What gets decided before a line is written

Serverless or containers — This is not a matter of fashion. Serverless functions are very cheap with irregular traffic and turn expensive and hard to debug under sustained load; containers cost a fixed minimum and do not surprise you. It is decided by looking at the real traffic profile, not the one you hope to have some day.
One provider or several — Splitting across two clouds sounds like prudence and doubles the work: two ways of doing networking, two of managing permissions, two invoices to reconcile. The design keeps moving possible and states explicitly which pieces are provider-specific, which is not the same as using none.
Where the data lives — The region is not chosen on latency alone. Moving personal data outside the European Economic Area means documenting the transfer and justifying the safeguards, and that constrains which managed services can be used. It is decided before building because afterwards it means moving data with the system running.
What breaks first — Before optimising anything, it is defined what counts as the system being down and how long is tolerable. Without that, high availability turns into overspending everywhere; with it, the money goes where it actually hurts and the rest stays simple.

What is not included

The cloud spend itself, contracted in your name and on your card.
Building new application features: this work moves and tidies what exists.
On-call rotas or 24/7 support, contracted separately.
Migrating systems whose provider will not let you export the data.
Security auditing: that is the cybersecurity service, and it comes afterwards.

What you need to have

Administrator access to the current cloud accounts, or to whoever holds it.
Knowing which applications are critical and how long they can be down.
An agreed window for the migration, if there is a live service.
Someone on your side who can confirm the migrated system works as before.

Frequently asked questions

Can the bill come down without breaking anything?

Almost always, and the first thing that turns up is whatever is running unused. Before touching the architecture I measure where each charge comes from.

What is infrastructure as code, and why should I care?

It means your infrastructure lives in versioned files instead of in clicks nobody remembers. It matters the day it has to be rebuilt, audited or explained.

Does this lock me into one provider?

It is designed so that moving is possible, and I state plainly which parts are provider-specific. Promising you will never be locked in would make everything else more expensive than you need.

How long does it take?

The audit is one or two weeks, and from there the work runs in sprints, each with a rollback plan. The total depends on how many systems move, and it is fixed in the quote.

Can you migrate without downtime?

In most cases yes, moving in stages and keeping both environments running in parallel for a while. When it cannot be done, that is said up front and the cutover window is agreed in writing.

What if my team does not know Terraform?

The handover includes an operations runbook and two days of training. Something written down is easier to learn than clicks nobody documented, which is the situation people usually come from.