A.01
Architecture
Patterns, coupling, seams, deployment topology. We map the modular boundaries that actually exist (not the ones the README claims) and flag where coupling is buying you nothing.
04 · Discovery practice
2-week technical discovery sprints & codebase audits.
A fixed-price, structured engagement that de-risks an upcoming Django, Wagtail or AI project before any production code is written. Two weeks. £8k flat. GDS-aligned. Procurement-ready outputs you can hand to a board, an SRO, or a build vendor.
You probably need a discovery sprint if…
- You've inherited a codebase you can't yet quote on with a straight face
- Your board has approved an "AI initiative" with no architecture, no cost envelope, and no idea what's reusable
- A procurement framework wants evidence of architectural viability before the Alpha phase
- You're choosing between build-from-scratch and a vendor and can't yet say which is cheaper at 24 months
- A migration is on the roadmap and nobody can size it within a factor of three
- You want a second, independent technical opinion before committing six figures
DS.01 / Assessment
Surgical multi-dimensional codebase assessment.
Two weeks is not a deep refactor. It's a structured assessment across four dimensions we've found give the highest signal for the lowest invasiveness. Each dimension produces evidence; the four together produce a prioritised, risk-sequenced roadmap you can actually execute against.
A.02
Dependencies
Every package, pinned or otherwise. Outdated, abandoned, license-incompatible, or CVE-exposed dependencies are flagged with a recommended replacement path and effort estimate.
A.03
Security
Credentials hygiene, authentication and authorisation flows, session handling, OWASP Top 10 alignment, dependency CVEs. We flag the issues — and the cheap fixes that close 80% of them.
A.04
Performance
Slow-query log, profiler output, cache hit-rate, async opportunities. We identify the bottlenecks that pay for themselves in the first week of a build engagement.
DS.02 / Cadence
How the two weeks actually play out.
No surprises. Day-by-day what we'll be doing, what we need from your team, and when each deliverable lands. A 30-minute checkpoint at the end of each week keeps you in the loop without consuming engineering hours.
D 01 · Mon
Kick-off & access pack
→ kick-off
D 02 · Tue
Architecture & seam mapping
architecture
D 03 · Wed
Dependency & SBOM scan
dependencies
D 04 · Thu
Security & auth flow review
security
D 05 · Fri
Week-1 checkpoint (30 min)
→ checkpoint
Sat / Sun
—
off
D 06 · Mon
Performance profiling & slow-query log
performance
D 07 · Tue
Build-vs-buy analysis
commercial
D 08 · Wed
AI scope & token-budget model
ai
D 10 · Fri
Final report & live exec briefing
→ delivery
Day 9 is reserved for synthesis, write-up and rehearsal of the final briefing. Real engineering work doesn't run at 100% utilisation — and neither do we.
DS.03 / Outputs
What you walk away with.
Five concrete artefacts, all written in language a non-engineer board member can act on. Yours to keep, share, or hand to another vendor — there are no platform licences, no proprietary formats, no "ask us for an export".
01
Risk-sequenced execution roadmap
A prioritised work plan — what to do first, what depends on what, what can wait. Each item has an effort estimate (in weeks), a risk score, and a "what happens if we don't" note.
02
Build-vs-buy analysis
For each major capability, a formal comparison of custom-build vs available third-party integrations across cost-at-24-months, vendor lock-in, customisation ceiling, and operational overhead.
03
AI token-budget envelope
If AI features are in scope: estimated tokens/request, daily token spend at three traffic tiers, model-choice trade-offs, and the cost cliff edges to watch for.
04
Prioritised remediation plan
For existing codebases: a quick-wins list (this week), a medium-term list (this quarter), and a strategic list (this year), each with effort, impact, and owner suggestions.
05
Executive briefing (live)
A 60-minute briefing to your stakeholders — board, CTO, SRO — walking through the findings and answering questions. Recording included; happy to re-present once for procurement.
06
Procurement-ready evidence pack
If you're heading into G-Cloud or a public-sector procurement, we include a GDS-aligned evidence pack: technical viability statement, accessibility considerations, exit strategy and supplier resilience notes.
DS.04 / Public sector
G-Cloud & GDS Service Standard alignment.
UK public-sector teams have a clear set of expectations from the Government Digital Service: separate Discovery, Alpha, Beta and Live phases; user-needs evidence; accessibility statements; open-source preference; viable exit strategy. We structure the sprint outputs around exactly these expectations, so the artefacts feed straight into your service assessment evidence pack.
// gds phase
What assessors look for
Where the sprint delivers it
discovery
Evidence of user needs, problem space, technical landscape and viable approaches.
Architecture & build-vs-buy outputs establish technical viability and frame the option space.
alpha → beta
A credible delivery plan, risk register, and route to a Minimum Viable Product.
Risk-sequenced roadmap doubles as the Alpha plan, with effort estimates suitable for budget sign-off.
tech choices
Use open standards, avoid lock-in, prefer open-source where appropriate, plan exit.
Build-vs-buy analysis scores each option on lock-in, exit, customisation ceiling and TCO at 24 months.
accessibility
A clear plan to meet WCAG 2.2 AA and the Public Sector Bodies Accessibility Regulations 2018.
Accessibility considerations are folded into the architecture review; a statement template is included if requested.
supplier & team
Evidence the team can build the service and the supplier can sustain it.
Supplier resilience notes outline our team shape, on-call model and exit transition plan.
DS.05 / Fit
Is the discovery sprint right for you?
Yes, if… we're a fit
- You're about to commit £50k+ to a build and want independent technical validation first
- You've inherited a codebase from an acquisition, a previous vendor, or a founding engineer who left
- An AI initiative needs scoping, costing and a build-vs-buy call before procurement signs anything
- A public-sector procurement requires GDS-aligned evidence of technical viability
- Internal stakeholders need a second opinion that isn't from the team being assessed
Probably not, if… consider others
- You want a 60-page report with no human conversation — we work in dialogue, not by RFP
- You need the report inside 5 working days; the sprint is genuinely 10 working days
- You want a guaranteed positive verdict — we'll tell you the truth, including "don't build this"
- Your stack is exotic enough that Django/Wagtail/Postgres expertise wouldn't transfer
DS.06 / FAQ
Common questions.
What's actually included in the £8k discovery sprint?
Two weeks of a senior engineer's time plus a specialist (security, AI or frontend, depending on the brief), structured across four assessment dimensions (architecture, dependencies, security, performance), an executive briefing, and four written deliverables: a risk-sequenced execution roadmap, a build-vs-buy analysis, an AI token-budget envelope (if applicable), and a prioritised remediation plan. Everything is GDS-aligned and procurement-ready.
Can the sprint inform a G-Cloud or public-sector procurement?
Yes — the sprint is structured around the GDS Service Standard. The outputs are the kind of evidence procurement and SROs need to secure budget and pass an architectural review for the subsequent Alpha and Beta phases. We're comfortable working under G-Cloud terms and producing the documentation public-sector clients need, including supplier resilience notes and exit transition plans.
What if we want to engage Webbyfox to do the build afterwards?
You can. The sprint fee is credited 100% against the first month of a build engagement if you proceed with us. But you're under no obligation — the sprint is designed to be a useful artefact on its own, and we've had clients use the outputs to brief an internal team or a different vendor entirely.
Do you need full production access?
No. We work from a read-only repository clone, a sanitised database snapshot, and (optionally) read-only access to logs and metrics dashboards. We never need write access during a discovery sprint. Access requests are listed in the kick-off pack, scoped to least privilege, and revoked on day 11.
What does the kick-off look like?
A 90-minute call on day 1. We meet your stakeholders, agree the success criteria for the sprint, walk through the access pack, and align on the briefing audience for day 10. From day 2 onward we're heads-down; you get a Friday checkpoint and a Slack/email channel for any clarifications.
Are you NDA-friendly?
Yes. We sign mutual NDAs as standard for all discovery engagements. Our template is straightforward and most legal teams approve it in under a week. Happy to work with yours instead.
What if the answer is "you shouldn't build this"?
Then that's the answer, and you've saved six figures and six months. We've recommended against builds twice in the past two years — once in favour of a SaaS and once in favour of doing nothing. The sprint fee is the same; the value of the answer is the same.
Got an inherited codebase
or an ambitious AI integration?
Book a 15-minute strategy call.
15-min strategy call
Free · same-week availability
Discovery sprint
2 weeks · £8,000 fixed · 2 slots / month
Lightweight audit
3–5 days · from £2,500