Platform, CI/CD & reliability

The part that decides whether the rest survives

Good application code on bad foundations still pages someone at 3am. Platform work is what makes quality repeatable instead of heroic: if a standard is not enforced by the build, it is a preference.

What we set up

• CI/CD that gates properly: typecheck, tests, accessibility and performance budgets on every pull request, with preview environments per branch.
• Infrastructure as code: environments reproducible from the repository, not from somebody's memory of what they clicked.
• Observability: logs, traces and real-user metrics wired so an incident is diagnosed from data rather than from guesses.
• Data you can actually restore: backups verified by restoring them, because an untested backup is a rumour.
• Security hardening: sane headers, least-privilege access, dependency and secret scanning in CI.

Boring where boring wins

We choose infrastructure for the scale you have plus the scale you can see, not the scale you hope for — the same instinct as in defence of boring databases. Specialise when a measured constraint demands it, and not a quarter earlier.

Handover, genuinely

Runbooks, architecture notes and access that belongs to you. The test of a handover is whether a team who has never met us can operate the thing — so that is the test we write it against.

How an engagement runs

We start by finding out what is actually true: how deploys happen, what is reproducible from the repository, whether the backups have ever been restored, and what a production incident currently looks like from the inside. That assessment is usually the most valuable document of the engagement.

Then we close the gaps in priority order — CI gates, preview environments, infrastructure as code, observability, verified restores, dependency and secret scanning. The aim is that quality becomes repeatable rather than heroic.

Common questions

We are a small team. Is this overkill?

The opposite — small teams benefit most, because they have the least slack to absorb an incident. The point is not elaborate infrastructure; it is that the boring things (deploys, restores, alerts) are automatic so attention goes to the product.

Do you take over running our infrastructure?

No. We set it up, document it and hand it over, because infrastructure you cannot operate yourself is a dependency, not an asset. We can stay on retainer for escalations, but ownership stays with you.

Which cloud do you work with?

Vercel, AWS and Cloudflare most often, and we choose for the scale you have plus the scale you can see — not the scale you hope for. Specialising early is one of the most expensive mistakes we get asked to unwind.