Try it at home first

My public GitHub looks nothing like my CV. The CV says production systems in specialty insurance. The GitHub says: a fork of privateGPT, a local RAG stack, OCRmyPDF, a sketch for diffing PDFs, a chatbot widget for Rasa, a self-hosting guide. Weekend stuff. Nothing with a pager attached.

That gap is deliberate, and it runs in one direction: the sketchbook comes first, the production system comes later.

I was forking OCR and PDF-rendering libraries years before I shipped a document-comparison system to hundreds of underwriters. I was running retrieval-augmented generation against my own documents, on my own hardware, before I put hybrid semantic search in front of an insurance organisation. The home lab is where the technology gets to fail privately, cheaply, and without a change-approval board watching.

In a regulated industry this matters more, not less. At work, every experiment carries overhead: data classification, vendor review, audit trails. All of it justified — that overhead is the immune system of a business that handles other people's risk. But it means work is a terrible place to find out whether a technology is fundamentally sound. By the time something reaches production planning, I want to already know where it breaks, because it broke on my desk first.

Running these things locally also strips the marketing off. A vector database on someone else's demo data is magic. The same database pointed at your own messy documents — scanned PDFs, tables, seventeen versions of the same contract — tells you the truth in about an hour. Most of what I now believe about retrieval quality, OCR failure modes, and document structure I learned from experiments that never left my house.

So the sketchbook stays public, unpolished, and honest. It isn't a portfolio; the production work lives in private repos and behind NDAs, which is rather the point. But if you want to know what I'll be shipping in two years, don't read my CV. Read the forks.