The playbook
The Secure Delivery Playbook
How software gets built here: the same discipline that runs this platform, written down so you can hold the work to it. Five principles, one delivery lifecycle, and the evidence pack you keep at the end.
The proof is not in this page — it is underneath it. The platform you are reading this on was delivered by the playbook it describes, and its architecture, security posture and test strategy are published for you to inspect. Delivery evidence, not a brochure.
Principles
Five principles that hold on every build
Not values on a wall — each one is a rule that changes what gets written, and each one is visible in the code and documentation of this platform.
Security is designed in, not audited in later
The threat model comes before the first endpoint: what an attacker would want, which surfaces expose it, and what the control is. The OWASP Top 10 is the floor, not the finish line — auth, authorisation, input handling, file upload and the data layer are built defensively from the start rather than hardened after a report lands.
Nothing is trusted at the boundary
Every request body, URL parameter and query string is schema-validated at the edge, and unknown keys are rejected rather than quietly ignored. Data access is raw parameterised SQL only — an injection payload is stored as literal text, never executed — and rendered output is escaped by default, with no raw HTML path through the markdown pipeline.
Access is denied by default
Accounts are invite-only: there is no self-signup endpoint to attack, and an account only exists because an administrator created it. Roles are double-gated — checked at the route and re-checked against record ownership in the handler — and a resource you have no right to see returns 404, not 403. That is deliberate: a 403 confirms the record exists, and confirmation is itself a leak.
Every claim is testable — including the security ones
A security test must fail when its protection is removed, or it proves nothing. Each one is verified by reverting the fix and watching it go red before it is trusted; a test that passes either way is decoration. That standard is what turns "we handle authorisation correctly" from a sentence in a proposal into something a reviewer can run.
Everything privileged leaves a trail
Privileged actions write to an append-only audit log — who, what, which record, from where, when — and audit rows are never deleted, only their IPs age out. Database migrations are forward-only and numbered, so the schema has one history and no silent edits. Backups are proved by restore drills that actually restore, because an untested backup is a hope, not a control.
The lifecycle
How an engagement actually runs
Five stages, in order. Each one produces something you can read, run or review — not just a status update.
- 01
Discover
A fixed-scope discovery sprint maps the problem, the users and the constraints, and agrees scope and success criteria before anything is built.
See the discovery sprint - 02
Design
Architecture, data model and threat model are written down as reviewable artefacts up front — including the decisions that were rejected and why, so the record survives the project.
- 03
Build
Small, reviewable slices with the tests written alongside the code. Every push runs the same CI gate: lint, a production dependency audit, unit and integration suites against a real database, end-to-end journeys, and an accessibility scan.
- 04
Verify
Automated WCAG 2.2 AA scans on representative pages, a security regression suite covering authentication, authorisation, tenant isolation and injection, and recorded performance baselines rather than adjectives.
- 05
Operate
Progress stays visible in your own portal — milestones, deliverables and sign-offs — and operations are governed: a documented incident procedure carrying the 72-hour GDPR breach-notification duty, plus retention and erasure tooling for data-subject requests.
Handover
What you hold at the end
The deliverable is not only the running software. It is everything a procurement reviewer, an auditor or your next engineer needs to take it on without asking us.
The code, and the ownership of it
The repository is yours, on your infrastructure, with no proprietary runtime and no per-seat licence standing between you and your own platform.
The security summary
The control set written the way a due-diligence questionnaire asks for it: each defence stated plainly and mapped to where it lives in the code.
The data-protection record
Where personal data lives, the lawful basis and retention position for each category, and the documented procedures for erasure, access requests and breach notification.
The test strategy
What is covered, at which layer, and — just as importantly — what is deliberately not covered, with the reason stated rather than omitted.
The deploy and rollback runbook
How a release ships, how it is verified, and the exact steps to put the previous version back if it should not have shipped.
No lock-in
Nothing in the delivery depends on this practice continuing to be involved. Another engineer can read the docs, run the tests and take it forward.
Receipts
This playbook describes what you can inspect, not what we intend
Every principle above is already running somewhere you can look at. Start with any of these three.
How this site is built
The architecture, schema, auth flow and deployment pipeline of the platform you are reading — assembled from its own architecture record.
Security
The commercial security position, plus three interactive demos of the real mechanisms: injection defence, the JWT lifecycle and RBAC.
Case studies
Delivered projects with the business outcome and the full technical architecture behind it, rather than a logo wall.
Every engagement starts with the discovery sprint
A fixed-scope piece of work that ends with a scoped, costed plan you own — whether or not the build follows. It is stage one of the lifecycle above.