Platform, Security & Operations
Cloud, DevOps and infrastructure
What this category covers
Building software and keeping software running are different jobs. This category is the second one — the work that decides whether what you built is still serving customers at half past eight on a Monday morning, what it costs you every month, and how quickly it comes back when something breaks.
The work divides into a number of recognisable jobs. Moving systems onto AWS, Azure or GCP without losing a day of trading. Reading a cloud bill line by line and cutting it without slowing anything down. Replacing hand-run deploys with a pipeline that builds, tests, ships and reverses on its own. Packaging applications into containers, and orchestrating them only where the size of the system earns that complexity. Putting infrastructure into code so it can be reviewed, rebuilt and audited rather than remembered. Metrics, logs and alerts so failures are found by the system rather than by a customer. Backups proved by an actual restore, with the time to recover and the data you would lose written down rather than assumed. Running the small, bursty pieces serverless instead of on a machine that idles. Hosting that somebody else patches, renews and watches. Domain records — SPF, DKIM and DMARC — that decide whether your mail reaches an inbox or a spam folder. And ongoing reliability engineering, where uptime is held to an agreed number with an on-call rota behind it.
The buyers are those for whom downtime has become expensive — businesses running operations on a system nobody documented, teams whose releases depend on one person's laptop, and products whose cloud bill has outgrown anybody's explanation for it.
The measure of success here is unusual and worth stating plainly. The good months are the uneventful ones. Nothing went down, the bill looked like last month's, and the release on Thursday was unremarkable. That is the product.
- Services
- 11
- Detailed pages
- 11
11
Cloud, DevOps & Infrastructure
11 services
-
01
Cloud migration (AWS / Azure / GCP)
A move from on-premise or old hosting into the cloud.
-
02
Cloud cost optimisation (FinOps)
The bill cut 20–50% without losing performance.
-
03
CI/CD pipeline setup
Automated build, test and deploy — release friction gone.
-
04
Containerisation & Kubernetes
Running and scaling applications on Docker and K8s.
-
05
Infrastructure as Code (Terraform)
Reproducible, version-controlled infrastructure.
-
06
Monitoring & observability
Logs, metrics, traces and alerts — problems seen first.
-
07
Site reliability engineering
Uptime SLAs, an incident process and on-call.
-
08
Backup & disaster recovery
Automated backups, restore drills, and an RTO/RPO plan.
-
09
Serverless architecture build
Cost-efficient, auto-scaling systems on Lambda or Workers.
-
10
Managed hosting & server admin
Setup, patching, SSL and uptime, on a monthly retainer.
-
11
Domain, DNS & email deliverability
SPF, DKIM and DMARC — mail that lands in the inbox.
How the work runs.
-
01
Scope
What you actually need from Cloud, DevOps & Infrastructure, written as deliverables rather than adjectives.
A day or two
-
02
Price and date
A fixed scope, a number and a delivery date, agreed before anyone starts.
Same week
-
03
Build
The work itself, with something you can open and look at rather than a status report.
The bulk of it
-
04
Handover
Files, access and a walkthrough. Nothing is held hostage.
Final day
See where the site stands before you brief anyone.
Before scoping Cloud, DevOps & Infrastructure work, it helps to know what the site is doing today. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.
Questions people ask before they commit.
- Where should we start if we are not sure what we need?
- Almost always with measurement. Monitoring tells you what is actually failing, and a cost review tells you what you are actually paying for — both are short pieces of work that produce evidence, and both make every larger decision cheaper to get right. Starting with a migration or a cluster before either of those is how budgets get spent on the wrong problem.
- Do we need all of this, or are these separate engagements?
- Separate, and deliberately so. You can buy one thing, live with it, and come back for another. The services do reinforce each other — a pipeline is more valuable when infrastructure is in code, and reliability work is far easier when monitoring already exists — but each stands alone and none of them requires the others first.
- What if our system is undocumented and the person who built it has gone?
- That is the normal starting position rather than an unusual one. The first phase of most of this work is reading the running system rather than the paperwork — what listens on which port, what runs on a schedule, where certificates come from, what holds data that cannot be recreated. The written map that comes out of it is yours regardless of what you decide to do next.
- Is this only for large companies?
- No, but the right answer scales down as well as up. A business with one application and a database is usually best served by a well-configured server, sound backups and honest monitoring — not by a cluster. We would rather tell you that than sell you infrastructure you then have to operate.
- How is ongoing work priced compared with projects?
- Project work is quoted as a range against a defined outcome, with the variables that move it stated up front. Ongoing reliability work is monthly, because the value is continuous — patching, capacity, incident response and the slow removal of the things that cause outages. Both are listed with their ranges on the individual service pages.
- Can you work with our existing team and tools?
- Yes, and that is usually the better outcome. Replacing tooling that works is rarely where the value is. Where a pipeline, a monitoring stack or an infrastructure repository already exists, improving it leaves your team with something they already understand instead of a new system to learn.