Cloud, delivery & engineering practice
The foundation everything runs on, and the pipeline that gets it there verifiably.
Environments defined as code and reproducible. Releases with signed provenance, so what is running can be verified rather than assumed. And the engineering practice that keeps it that way as AI writes more of the code.
Why this matters now
The way attackers get in has shifted from stolen passwords to software nobody patched and suppliers nobody checked. At the same time, AI workloads have made cloud bills harder to predict and easier to waste. Both problems have the same root: environments nobody can fully describe, built by hand, running software nobody can fully account for.
What we build
Foundations
Foundations: zero to production
For a client starting from nothing, we stand up the whole environment — what runs where, how it is isolated, how it scales and what it costs. Built as infrastructure-as-code and handed over so it is reproducible and yours outright.
Where it applies: a company moving its first product off a single server · a new business unit that needs its own secure environment.
Cloud architecture
Designing or redesigning what runs where, how it is isolated, how it scales and what it costs. Every decision written down with its reasoning, and the result expressed as code.
Where it applies: cutting a cloud bill that has grown without anyone owning it · separating production from test after a near-miss.
Sovereign & private AI deployment
Models run inside an EU sovereign cloud, a private cloud or your own data centre when your data, regulator or customers require it. Open-weight models served, scaled and monitored like any other production service, measured against the same evaluation set as the hosted model they replace.
Where it applies: a bank or health provider whose data cannot go to a US model API · a European SaaS vendor whose customers demand EU-only processing.
Portability & exit
Infrastructure built so you can actually leave — infrastructure-as-code that redeploys elsewhere, a written exit plan and a tested migration. Also the exit strategy DORA requires financial firms to hold.
Where it applies: an EU bank documenting a DORA exit strategy for a critical cloud or AI vendor · a company negotiating a cloud renewal with a credible alternative.
Delivery and operations
Delivery pipelines
Automated build, test and deployment. Every release carries signed build provenance and a dependency inventory, so what is running in production can be verified rather than assumed.
Where it applies: replacing manual deployments that happen late on Friday nights · answering customer security questionnaires about the software supply chain.
MLOps
Deploying, versioning and monitoring models and the pipelines that feed them — including what happens when a provider deprecates a model or changes how it behaves.
Where it applies: retraining and redeploying a forecasting model safely each month · switching model providers without breaking production.
Operational readiness
Logging, monitoring and alerting configured before launch, and a runbook written for your team, not for us.
Where it applies: preparing a system for its first on-call rota · taking over a system from a supplier who left no documentation.
CRA-ready delivery
Your pipeline's dependency inventory extended into what the EU Cyber Resilience Act requires — vulnerability intake and triage, detection of actively exploited vulnerabilities, secure update delivery, and a reporting runbook. We build the reporting pipeline; you remain the manufacturer who files.
Where it applies: a software vendor that must report exploited vulnerabilities · a device maker preparing for CE marking.
Cryptographic inventory
A list of where your systems use cryptography that post-quantum migration will replace, ranked by risk, sitting beside your dependency inventory.
Where it applies: a financial or public-sector supplier asked for a post-quantum migration plan.
AI-native engineering
Coding-agent rollout
Coding agents deployed to a pilot team inside your own tools and repositories, with shared instructions, reusable skills and sandboxed execution — then a playbook so the next team can adopt them without us.
Where it applies: an engineering organisation whose developers use AI tools ad hoc with no standards.
Harness engineering
The guardrails that make agent-written code safe to merge — quality gates in CI, mutation testing, dependency and provenance checks, and review rules that scale with the extra volume of code.
Where it applies: review queues overwhelmed by AI-generated pull requests · rising defect rates after teams adopted coding agents.
Delivery measurement
Delivery baselined before we start and measured after — lead time, change failure rate, rework and review load. We do not report lines of code written as productivity.
Where it applies: justifying AI tool licence spend with evidence · comparing teams that use coding agents with teams that do not.
What comes with it
- Everything as code, reproducible from source, in repositories you own
- Signed build provenance and a dependency inventory on every release
- No long-lived credentials — short-lived, automatically expiring access only
- Monitoring and a runbook in place before launch
- Cost controls configured from the start
Built secure and evidenced, as standard
Built so what is running can be verified.
- Security and compliance are not a separate service we sell. They are how the work is built, on every engagement.
- For infrastructure and delivery, that means three things in particular. Our pipelines meet SLSA Build Level 3 — every artifact carries a signed record of what source it was built from and by which pipeline, verifiable with your own tooling. We do not use long-lived credentials anywhere; access is granted through short-lived tokens that expire on their own. And every environment is defined in code, so nothing significant exists only because someone configured it by hand.
- Everything we build in this area is delivered against our published engineering standard, and ships with the evidence to prove it: signed build provenance, a software bill of materials, and a runbook.
How the work runs
- 01
Scoping — what runs where, what it costs, who may reach it.
- 02
Design — architecture and threat model, written down.
- 03
Build — against the published standard, every merge reviewed.
- 04
Handover — in repositories you own, with documentation and a runbook.
Typical duration: 1 to 10 weeks. Operational readiness added to an existing build can take a week; a sovereign AI deployment or a full coding-agent rollout sits at the long end.
How we workWhat we will tell you
If an environment is more complex than the workload requires, we will simplify it — even when that means less for us to build and less for you to pay. And we build everything so you could take it to another provider, or another supplier, without us. Lock-in is a cost, even when nobody puts it on the invoice.
Tell us what you’re building.
Describe the problem in your own words. We will tell you honestly whether we are the right people for it.