Building VisaVault — a UK visa document platform from zero to launch

01 — The problem

A £1,500 problem hiding in plain sight

Every year, hundreds of thousands of people apply for UK visas — Skilled Worker, Student, Family, ILR. The majority are perfectly capable of preparing their own applications. The documents are standard. The requirements are published by the Home Office. The process is well-defined.

But the complexity feels overwhelming. So applicants pay immigration solicitors £1,500–3,000 to do what is largely a document preparation exercise — gathering the right papers, writing a covering letter, and following a checklist. The advice they are paying for is mostly bureaucratic navigation, not legal expertise.

The opportunity was clear: build a product that does the navigation and document preparation work at a fraction of the cost, with the consistency and accuracy that software can deliver at scale.

02 — Our approach

Product-led from day one

We approached VisaVault as a product build, not a website build. That distinction matters. A website is a brochure. A product has users who depend on it, data that must be protected, and logic that must be correct every time — because incorrect advice on a visa application causes real harm.

"Incorrect advice on a visa application causes real harm. We designed every system with that consequence in mind."

The product needed to do three things exceptionally well. Guide the applicant through a structured data collection process. Use that data to generate a personalised document checklist and covering letter via AI. And deliver the output in a format that is immediately useful for a UKVI submission.

We also had to build within strict constraints. UK GDPR applies to immigration data — passport numbers, dates of birth, and travel history are highly sensitive personal data. The AI integration had to be designed so that this data never crossed the boundary into Claude's context window. We built a sanitisation layer that strips all PII from prompts before they leave the server, with unit tests that enforce this on every deployment.

03 — Key challenges

Four problems that required careful thinking

04 — What we built

19 sprints. A complete product.

We structured the build as 19 discrete sprints, each with a definition of done verified before the next sprint began. This kept the codebase clean and made it easy to hand off individual sprints to specialised agents or developers.

05 — Technology

A modern, production-grade stack

Every technology choice was made for a reason — performance, security, cost, or maintainability. Nothing was chosen because it was fashionable.

06 — Compliance

GDPR was a design constraint, not an afterthought

Immigration data sits at the intersection of several sensitive personal data categories under UK GDPR. We treated compliance as a first-class engineering requirement from the first sprint, not something to retrofit before launch.

Data minimisation at the AI boundary. Only the fields Claude needs to generate a checklist are sent to Bedrock — visa category, nationality, current immigration status, employer details. Passport numbers, dates of birth, and passport expiry dates never leave the server.

Retention automation. An admin data hygiene panel tracks every case's last accessed date. Cases inactive for 12 months are automatically flagged for anonymisation — PII fields nullified, S3 documents deleted, generated content removed. EventBridge runs this sweep daily.

Audit logging. Every significant action — payment, AI call, pack download, anonymisation — is written to an audit log table with a timestamp. When a GDPR subject access request arrives, the full history of what was done with that user's data is immediately available.

ICO registration. Registered with the Information Commissioner's Office before the first user was onboarded. DPAs signed with every sub-processor — Anthropic, AWS, Supabase, Clerk, Stripe, Resend.

07 — The result