This follows on from: Generative AI for Genealogy – Part X
TL;DR
This chapter chronicles my journey from a fat‑client genealogy app to a fully web‑based version — and the chaos, comedy, and security lessons that followed. I used vibe‑coding (GPT‑powered development) to build the SPA UI, authentication flow, GEDCOM upload pipeline, chat interface, and even multi‑language support. It was fast, impressive, and occasionally terrifying.
Along the way, I discovered that vibe‑coding will happily implement whatever you ask, including things that violate best practice, revenue protection, and common sense. I rebuilt authentication properly, added device fingerprinting, implemented Stripe payments, and created a pilot‑mode system. Codex helped, but it also broke things it had written earlier, proving that AI still needs experienced oversight.
The takeaway: AI accelerates development dramatically, but it’s not a senior engineer. Yet. And now that the web UI is solid, it’s time to make the AI side of the project just as powerful.
Feeling The Vibe?
There’s a particular smell that comes from spending years building web‑apps in ColdFusion with Oracle backends. It’s somewhere between nostalgia and Stockholm syndrome. My fintech stack today is Lucee (still CF, because old habits die harder than Bruce Willis), Postgres, and a constellation of C# REST APIs. In other words: I’ve been building web‑apps long enough that I could probably assemble one in my sleep, and on more than one occasion I suspect I actually have.
So when I found myself, over the last few days, staring into the middle distance and questioning my life choices, it wasn’t about the tech stack. It was about the fat client.
Rethinking the Fat Client
Don’t get me wrong, my heart was in the right place. I wanted a rich, responsive, local-first experience. But then the practicalities started tapping me on the shoulder like an impatient librarian. Shipping EXEs and DLLs to genealogists? Expecting them to run installers? Requiring a cloud endpoint for updates? And then the pièce de résistance: “Please deploy GPT4All locally using this scripted process.” Most genealogists are not software developers. Many are still traumatised from the day Family Tree Maker changed its toolbar icons.
Can I Cheat the System (Just a Little)?
So I started wondering: could I cheat the system, at least for the pilot phase? And to my surprise, the answer was a resounding yes.
If a user uploads a GEDCOM to the cloud, and I keep it in memory rather than writing it to disk, am I breaking any sacred genealogical commandments? Probably not. After all, many genealogists happily upload their entire family history to Ancestry, which stores it on disk, in a database, on servers they will never see. Compared to that, my approach is practically artisanal.
And the numbers? Surprisingly forgiving. My own tree, a sprawling 35,000‑person epic weighs in at around 50MB as text. Parsed, it’s roughly the same size. If ten users uploaded trees that large simultaneously, that’s about 500MB of RAM. Half a gig. Most users will have smaller trees, so realistically I could support maybe 50 concurrent users before anything starts sweating. For a pilot, that’s more than enough runway.
The system automatically clears trees after inactivity, and each user only ever has one tree in memory. Simple. Clean. No disk. No drama.
