Got a project?

Get in touch
All work

SA Wills Database — estate-readiness platform

The model gathers the facts. It never writes the will.

A POPIA-resident platform for drafting, registering and releasing South African wills, where the legally binding text comes from deterministic rules and an approved clause library rather than from a language model.

Client
SA Wills Database — estate-readiness platform
Year
2026
Role
Sole developer — architecture, backend, privacy boundary, document pipeline
SA Wills Database — estate-readiness platform website
af-south-1
Where every byte stays
0
Legal clauses written by an LLM
~57k
Lines across web, core and AI service

Context

Most South Africans die without a will, and the estate that follows is a mess their family has to clean up during the worst month of their lives.

The build goes after the smallest version of fixing that which is still worth shipping: draft a will and a living will through a guided wizard, generate the print-ready documents, version and register them, and release the right documents to the right people once a death is verified.

The problem

Two constraints decide the whole architecture, and they are not negotiable.

The first is legal. A will is either valid or it is not. That is not a judgement you delegate to a model. If a model invents a clause or quietly drops a residual beneficiary, the output is not a bad autocomplete you can shrug at — it is a defective legal document that surfaces years later, when the person who could have corrected it is dead.

The second is POPIA. Personal data, and the processing of it, has to stay inside South Africa. That quietly disqualifies most of the convenient managed backends, because none of them host in af-south-1. It also disqualifies the commercial models worth using, all of which run in the United States — the one place the data is not allowed to go.

What I did

I split the system along the line the law draws, not the line the framework suggests.

The Wills Act validity checks and the estate-duty and CGT arithmetic are ordinary auditable code in the NestJS core, organised as a module per problem area — will, living-will, legal, vault, audit, rbac, rls, death, dha, retention, document. Documents assemble from a structured, versioned clause library into HTML and then to PDF via Gotenberg, and every generated PDF is hashed into an append-only, hash-chained audit log. Tenant isolation is row-level security in Postgres rather than a WHERE clause somebody can forget.

The Python FastAPI service is the only component permitted to reach an external model, and it strips personal data out — Presidio plus custom South African recognisers — before a request leaves the country, then rehydrates the result on the way back. The network boundary and the privacy boundary are deliberately the same wall, so crossing one means crossing the other and both are enforceable in code.

The model’s job, when it is switched on, is to gather facts and propose clauses from the approved library. The deterministic rules decide what actually lands in the document. AI-guided interviewing is scaffolded but explicitly a later phase, because the first shippable slice does not need it and the legal risk of shipping it early is asymmetric.

The result

An estate document that a registry can stand behind: version-controlled, hash-chained, resident in Cape Town, and legally valid because auditable code said so.

The status is worth stating plainly, because the temptation in this category is to overstate it. This is a greenfield MVP on an internal review deployment. It is not publicly live and not yet legally signed off. An adversarial review of the spec produced a set of do-not-ship findings, each mapped to the phase it gates, and the Home Affairs death verification is still a stub. The two rules the design rests on — no model output in legal text, no untokenised personal data across the egress line — are the ones that get tested as invariants rather than features.

Got something like this that needs building?

A few lines about what you’re trying to build or fix is enough. It lands in my inbox and I reply within the business hour — honestly, including whether I’m the right person. If I’m not, I’ll say so and point you at someone who is.

I reply to every enquiry within one business hour.

Prefer email? support@yourdesign.co.za· (+27) 079 177 1970

Next case study — EdenFinTech — equity research pipeline →