Services/Four engagements

Everything here ends with a document you own.

We don't do open-ended retainers as a first engagement. Each of these has a fixed scope, a fixed duration and a delivery date, so you can decide whether the work was worth it without arguing about hours.

Every engagement includes: a written deliverable, two live walkthroughs, and 30 days of email follow-up. Invoiced 50% at kickoff, 50% on delivery. Net 14.

01

Architecture review

Two weeks · read-only · one written report

A second pair of senior eyes on infrastructure that has grown faster than the team that owns it. Most of our clients are between 15 and 45 engineers, three to six years into a cloud migration nobody planned as a migration.

We read the account, not just the diagrams. Network topology and security groups, IAM roles and who can actually assume them, backup and restore paths (we ask for a restore, not a backup policy), deployment pipelines, log retention, and the three or four places where a single misconfiguration would take you down for a day.

Written review, 18–25 pages, in plain language your board can read
Risk register: 12–20 findings, each with likelihood, blast radius and a rough dollar figure
90-day remediation roadmap, ordered by risk-per-hour-of-work, with owners
90-minute walkthrough with your engineers, recorded if you want it
One follow-up call at day 30, once you've started fixing things

We don't touch production. Access is read-only for the whole engagement, and we ask for a separate role rather than your admin credentials.

02

Cost optimisation

Three to five weeks · fixed fee · savings tracked for 60 days

Fourteen of these so far. Median reduction in compute and egress: 38%. The first 15% is almost always boring — orphaned EBS volumes, idle load balancers, a NAT gateway carrying more traffic than the app it serves, logs retained for 400 days because someone copied a config in 2021 and nobody has looked since.

The rest is structure: workloads sized for a launch that happened two years ago, three environments where two would do, a data warehouse scanned by dashboards nobody opens. We map spend to services and teams so the number stops being one opaque figure and starts being a list of decisions.

Line-item analysis: every service, by environment and by owning team
Tagging and allocation model, applied — not just recommended
Right-sizing plan with a risk note against each change (what breaks if we're wrong)
Commitment strategy: Savings Plans or reserved capacity, with break-even maths spelled out
Budgets and anomaly alerts configured in your account before we leave
Savings tracker so you can see whether the reduction held after month two

We charge a fixed fee, never a percentage of savings. A share-of-savings deal gives a consultant a reason to make month one look spectacular and then disappear.

03

Incident readiness

Four weeks · includes a facilitated game day

We call it the 3am test: could a tired engineer who joined four months ago, working from a laptop in a hotel room, resolve your most likely outage without waking anyone else up? For most teams the honest answer is no — not because the engineers aren't good, but because the knowledge lives in one person's head.

This engagement is mostly writing and deleting. We write SLOs that reflect what customers actually feel, and we delete alerts that page humans for things a dashboard should tell them. In most accounts we remove more alerts than we add.

SLI/SLO definitions for your three critical user journeys, with error budgets
Alert review: severity ladder, routing, and a list of what we removed and why
On-call rotation, escalation policy and a written compensation policy for out-of-hours pages
Runbooks for your top three failure modes, tested during the game day
Incident comms templates: status page, customer email, exec update, postmortem
Two-hour facilitated game day with your team, plus a findings memo

We won't be your on-call. A two-person firm covering someone else's 3am is a promise nobody should make — and if we did, you'd be the one finding out it was a bad idea.

04

Migration

Six to ten weeks · phased cutover · rehearsed rollback

Cloud-to-cloud, region-to-region, or data centre to cloud. The technical work is usually the easy part; the hard part is deciding what to leave behind and being honest about how long the cutover window really needs to be.

We plan in phases with a checkpoint after each one, so you can stop at any point without having half-migrated infrastructure. Every cutover gets a rehearsed rollback — rehearsed, not written. If we can't roll back inside the window, we don't cut over.

Dependency map of every workload, including the ones nobody remembers deploying
Target architecture with a before/after cost model (monthly, not annualised to look smaller)
Phased cutover plan with checkpoints, owners and go/no-go criteria
Rollback procedure, rehearsed in a staging environment and timed
Data sync verification: row counts, checksums, and a lag report you can read
DNS and TLS cutover runbook, written for whoever is on shift that night
Two weeks of hypercare after the final cut, then a decommission checklist

Around one enquiry in four ends with us recommending against migrating. That's not a sales tactic — moving a stable system to save 12% usually costs more than 12%.

05

How an engagement actually runs

Same rhythm every time. You'll know what's happening in week three without asking.

Week 0Kickoff call, 60 minutes. Scope, access, one named contact on your side, and the date the report lands. We send a one-page scope note afterwards; if it doesn't match what you expected, we fix it before invoicing.
Week 1Access and evidence. We read, we query, we interview two or three of your engineers. You get a short note at the end of the week listing what we've found so far — no surprises at the end.
Week 2–3Analysis and drafting. We may ask for a second interview; we try not to. This is the quiet part.
DeliveryWritten deliverable plus a 90-minute walkthrough. You get the document in markdown and PDF, and the diagrams as source files.
Day 30Follow-up call. What did you fix, what did you ignore, and were we wrong about anything. We keep a note of that last one — it's the only honest way to improve.

Boundaries

What we don't do

A short list, because it saves everyone a call. We're two senior engineers; anything outside this list would mean subcontracted strangers on your account, which is exactly what you'd be paying us to avoid.

No 24/7 coverNo NOC, no on-call, no "we'll monitor it for you".
No staff augWe don't rent engineers by the month into your team.
No compliance stampsWe'll prepare you for a SOC 2 or ISO 27001 audit and sit in the room. We won't sign the attestation.
No resellingNo cloud credits, no vendor partnerships, no commission on anything we recommend.
No greenfield buildsWe improve systems that exist. If you need a product built, hire a product team.