KeyProof went live this month: a verification product for UK car hire firms, built by Bygild as the build partner behind it. Before every handover the renter proves who they are with photo ID matched to a live selfie, passes a DVLA licence check, signs the agreement and photographs the car's condition. Which means the product touches ID documents, faces and driving licence records. For a small product, it is hard to pick a more sensitive set of data.

The normal way small products handle this is to build the thing first and write the privacy notice after. The lawyer-shaped work happens at the end, shaped around whatever got built. We did the opposite, and the point of this post is that doing the opposite changed the product itself, mostly for the better.

The DPIA came before the code

A data protection impact assessment sounds like paperwork. Done at the right time, it is actually a design review. Before any verification flow touches real data, the DPIA forces the questions that decide the architecture: what data does this step genuinely need, where does it live, who can see it, how long does it exist, and what happens when it goes wrong.

Asked at the end, those questions produce a document. Asked at the start, they produce a different system.

Store results, not documents

The single biggest decision: KeyProof stores verification results, not the documents behind them. The operator sees "identity verified" and "licence clear". They do not get a folder of passport scans, because there is no folder of passport scans.

Every version of this decision made the product better. There is less to breach, less to secure, less to explain in the privacy notice, and less for anyone to misuse. When we designed the pickup step, where the operator confirms the person collecting the car is the person who verified, the same rule held: the operator views a face reference, scoped to their own bookings and deleted on schedule. They never hold a copy of the ID.

Constraints like this feel like they should cost features. In practice, the features we are proudest of exist because storing something was not allowed.

Retention is code, not a promise

Most privacy notices contain sentences like "we keep your data no longer than necessary". Almost none of them are connected to anything. The sentence is a hope, and the data sits there for years because deleting things is nobody's job.

On KeyProof, the retention promises in the privacy notice are enforced by scheduled jobs. The checklist mailing list, for example, is swept automatically: an address that has had no contact for twelve months is deleted, because that is what the notice says happens. If the wording and the code ever disagree, one of them is a bug.

This is the cheapest form of compliance there is. A policy without a mechanism depends on someone remembering. A scheduled job does not forget.

Let regulated specialists hold the riskiest data

The highest-risk checks, matching a face to an identity document and reading a licence record, are exactly the checks where specialist regulated providers exist. Using them is usually framed as a build-vs-buy decision. It is also a data decision: if the specialist performs the check and returns the result, the platform holds less, and the riskiest processing happens inside an organisation audited for exactly that job.

The boring table that makes marketing lawful

One more, from the unglamorous end. KeyProof's site offers a free handover checklist by email. Every signup stores a consent record: what wording the person agreed to, which version, when, and from where. Nobody will ever admire that table. But it is the difference between a mailing list you can defend and one you quietly hope nobody asks about, and under PECR the asking can get expensive.

What this means if you run a small firm

None of the above needed a compliance team. It needed the questions asked at design time instead of after launch, which is the cheap moment to ask them. Retrofitting any one of these decisions later would cost more than all of them cost together up front.

The full build is written up as a case study: [KeyProof: the work](/work/keyproof). And if your product touches identity data and the plan is "privacy notice at the end", it is worth knowing that the order is the decision.