How we work
A delivery system you can audit.
Four steps. Named people. Artefacts that a founder, an operator, and an auditor can all read. We will not skip the first step to look faster.
01
Discovery & Architecture
Current-state mapping, target architecture, threat and data-protection baseline, integration landscape, and a delivery plan founders, operators, and boards can all defend.
Typical artefacts
- Architecture decision records
- Security & NDPR baseline
- Programme roadmap
- Risk register
02
Team Assembly
A right-sized, senior team matched to the work — product, operations, or regulated delivery. Named architect, delivery lead, and security lead — not a rotating cast of résumés.
Typical artefacts
- Named core team
- RACI and cadence
- Working agreements
- Environment access plan
03
Build & Secure
Iterative delivery against the architecture. Secure-by-design reviews in the same sprint as features. Test evidence that an operator or auditor can read without a translator.
Typical artefacts
- Working increments
- Control evidence pack
- Test & UAT records
- Change log
04
Scale & Support
Hypercare, knowledge transfer into your team, SLAs that mean something, and a backlog for the next horizon — not a vanishing act after go-live.
Typical artefacts
- Runbooks & SOPs
- Capability transfer
- SLA & support model
- Horizon-2 backlog
What we will not do
- Start a build before the target architecture and security baseline exist in writing.
- Staff a programme with a bench the client has not met.
- Treat NDPR, records, and audit trails as a later phase.
- Vanish after go-live. Scale & Support is a step, not a slogan.
Next step
If the first step is architecture, we should start there.
If the work needs architecture, security, and a team that will still be there at go-live, we should talk. Discovery conversations are with a senior architect — not a queue.