A Family Member Built an App for 223 Relatives. I Helped Make It Better.
How I planned a phase-by-phase upgrade for a family heritage platform — starting from a working codebase, not a blank page, and learning when not to rewrite everything.
The short version
My cousin built a family tree platform for 223 relatives in Central Java. It works. Now it needs privacy features, better engagement, and eventually an AI that interviews elders over WhatsApp. I planned the upgrade using the Stella & Satellite methodology. The first lesson: don't touch what already works.
The Starting Point
My family member Arief built something impressive.
A working web platform for 223 members of the Trah Karyo Redjo family — an extended Javanese network based in Central Java, Indonesia. It has a zoomable family tree, photo galleries, event management, and a full admin system.
He built it solo. People actually use it.
Now the family wants more.
What They Asked For
Three things, in order of urgency.
First: privacy. Right now, anyone with the URL can see every member’s phone number, home address, and photo. No login required. Google can index all of it.
Second: engagement. Features that bring people back regularly — not just once when they first discover the site.
Third: something ambitious. An AI that interviews the eldest family members over WhatsApp and turns their stories into published profiles on the platform.
My job: take a working codebase and a 20-feature wish list, and turn it into a build plan that won’t break what already exists.
The First Instinct (and Why I Killed It)
The platform runs on Node.js, SQLite, vanilla HTML and CSS, and a $6/month server.
My Shaka Satellite — the one I use for architecture decisions — flagged the obvious question immediately: should we migrate? Move to Next.js, add TypeScript, deploy to Vercel?
I killed that idea.
A rebuild would mean four to six weeks of work before a single new feature reached any family member. Arief built a codebase that 223 people depend on. Throwing it away to use technology I find more interesting isn’t a product decision — it’s an ego decision.
No migration. Improve what’s there.
The Real Problem First
Before any new features, there’s a security issue that needs immediate attention.
The platform is completely public. No login. No gating. Google can index every family member’s full name, phone number, home address, and photograph.
The family’s stated goal is complete privacy. Nothing else gets built until this is fixed.
The Plan
I worked through the full feature list and organized everything into five sequential phases.
Each phase must be complete before the next begins. This isn’t arbitrary — each phase is a dependency for the one that follows.
Phase 2A — Privacy & Access
Five steps, in this exact order.
Step 1: Stop Google from indexing the data. Two lines of configuration. Takes 30 minutes. Immediately stops new family member data from appearing in search results.
Step 2: Add login for family members. Separate from the existing admin account. Members register and link to their profile in the database.
Step 3: Two levels of access. Guests see blurred photos and abbreviated names. Logged-in members see everything. This protection sits in the server code — it can’t be bypassed by inspecting the page source.
Step 4: Branch coordinators. Each family branch gets a coordinator who manages their section without touching the whole database. Takes admin load off Arief.
Step 5: Per-member privacy controls. Each person controls what’s visible about them — who sees their phone number, address, and photos.
Nothing from Phase 2B ships until Phase 2A is complete. Auth is the dependency everything else needs.
Phase 2B — Reasons to Return
Features that give verified family members a reason to visit regularly, not just once.
A countdown to the next family reunion. A skills directory — find the cousin who does legal work, the family member who teaches. A relationship calculator: enter any two members, get back a plain-language explanation of how they’re connected.
Also: event RSVPs, and a way for members to submit corrections to their own profile, reviewed by the branch coordinator.
Phase 2C — Media
Maps for event venues using a free library — no API key needed. A photo reporting button so members can flag inappropriate uploads.
Video support in galleries: HTML5 video, MP4, 50MB limit. And automatic watermarking on all photos: “Trah Karyo Redjo — Family Only.”
Phase 2D — Paid Integrations
WhatsApp login for elders who don’t use passwords — a code sent to their phone. WhatsApp notifications for registrations, event reminders, and approvals.
AI photo restoration for old family photographs.
Phase 2E — The Elder Interview Project
This is the feature the family is most excited about.
The system sends interview questions to elderly family members over WhatsApp — one question every couple of weeks. They reply by text or voice note, in their own time and language. After six to eight questions, an AI compiles the responses into a published family profile on a “Family Stories” section of the platform.
It’s also the most complex, the most expensive, and the most likely to need iteration. It ships last — after every other phase has proven stable.
The Database Rule
Every change uses the safest possible approach: add new columns with default values. Never delete existing data. Never restructure existing tables.
All 223 family member records survive through every phase, unchanged. If any phase introduces a problem, it can be rolled back without touching the data.
The Honest Failure
My first draft included a full tech stack migration.
Next.js, TypeScript, Vercel, the works. It looked clean on paper. Then I calculated the timeline: four to six weeks of rewriting existing functionality before a single new feature could ship.
The family would wait two months to get privacy controls they needed immediately.
My Shaka Satellite flagged it before I got too far: a migration solves an engineering problem, not a user problem. The users don’t care about the tech stack. They care about whether their phone numbers are visible to strangers.
I had planned what I found interesting to build, not what the family actually needed.
What Happens Next
Phase 2A starts with the two-line configuration change that stops Google indexing family member data. Thirty minutes of work, immediate impact.
Then login. Then the two-tier visibility system. The plan is in the repo. The build starts now.
Links
- Original platform (Arief’s work): github.com/muhamarief/trahkr-fam-app
Satellite: Shaka (architecture) · Pythagoras (PRD) · Morgans (this post)
Pipeline: DISCOVERY — Pythagoras Exp → Shaka → Pythagoras Doc → Morgans