The Secure Discovery Sprint
In weeks, not months: a threat model against your real data flows, an architecture with the security decisions written down, and a costed plan you can take to any builder — including us.
Who it’s for
An SME or public body with something to build
You have a system to commission and you need to know what it costs and what it risks before you commit a budget to it.
An existing app you don’t fully trust
It works, but nobody can tell you whether it is safe. The review variant of the sprint leans towards security assessment of what already exists.
A security-conscious or regulated buyer
You are answering NIS2-cascade questionnaires from your own customers, and you need documented answers rather than assurances.
What you get
Four artefacts, all of them written to be read by someone other than us.
A threat model
Built against your actual data flows — who touches what, where it crosses a trust boundary, and what the realistic attacks are. Not a generic OWASP checklist.
An architecture
The system as it should be built, with the security decisions written down and justified: how auth works, where authorisation is re-checked, how data is stored and separated.
A scoped, prioritised roadmap
The work broken into increments that ship, ordered so the risky and load-bearing parts land first — not the easy parts first.
A fixed-fee proposal for the build
A costed plan for delivering it, fixed and agreed before any build starts. Accept it, or take the rest and go elsewhere.
Everything is yours — no lock-in
The deliverables are designed to be handed to any competent team. No proprietary format, no dependency on us to interpret them, nothing withheld to make the next step easier to sell. If you take the output and build it elsewhere, the sprint did its job.
How it runs
One to three weeks depending on scope, agreed before we start.
- 01
Discovery + threat modelling
Sessions with the people who know the system and the constraints. We map the data, the users, the integrations and the obligations — then model what an attacker would actually do with them.
- 02
Architecture + prototype spike
The architecture takes shape and the security decisions get written down. Where a question is expensive to get wrong, we spike it in code rather than argue about it on a slide.
- 03When scoped
Roadmap, proposal + playback
When the scope runs to three weeks: the roadmap and fixed-fee proposal are finished and walked through with you in a playback session, so the handover is a conversation, not a PDF.
Why us — checkable, not asserted
The discipline is the product: security tests that fail without their fix, non-enumerating authentication, privileged actions audited. You don’t have to take that on trust — these pages show the working.
How this site is built
This platform, graded by the standards it sells: the architecture, the auth flow and the deploy pipeline, in full.
Security posture & Lab
The real mechanisms, interactive: SQL-injection defence, the JWT lifecycle, and RBAC you can poke at yourself.
Case studies
Delivered platforms with their business outcomes and their technical architecture written up alongside.
Price
Price on request
Fixed and agreed before we start. No day-rate meters, no variation on the invoice you didn’t approve. The scope and the fee are settled together, in writing, at the outset — tell us what you’re trying to build and we’ll quote it.