Lantern.

Who it’s for

I built it for the adult children of an aging parent and the circle around that parent: the child doing most of the organizing, family who live farther away, a paid caregiver, and the parent, who reads what is shared with them, sees a count of what is not, and always sees who is in the circle.

That is who it is built for, not who has used it. No family has used it yet, and the interviews that would test it have not started.

What I built

I make the product calls and build it with AI-assisted workflows. AI writes most of the code; I decide what it builds and review what comes back.

On its first day, 11 August 2026, the web app already ran a family circle’s shared log, its task list and a Circle page on demo data, and 33 tests covered the permission rules. The real database, with tests that keep one family from seeing another’s, landed 2 days after the first commit. A readiness assessment 17 days in rated it ready for a guided demo on seeded data, and not ready for real families until real sign-in exists.

What it does now, on demo data:

• Four roles, named the way families organize: parent, organizer, family and caregiver. What each role may do sits in one table I can audit, not in checks scattered through the code.
• Three tiers of who sees what. Each log entry and task is marked for everyone in the circle, family only, or family private. The tiers form a strict chain, and a paid caregiver never sees the family tiers.
• Tasks start unclaimed. Anyone allowed can claim, release or complete one, and a task can be flagged as something family far away can do.
• Replies follow their entry. A reply has no privacy setting of its own, so a reply under a private note is exactly as hidden as the note.
• Edits say so. An edited entry carries an “edited” marker, and an edit cannot change who sees it. Deleting asks for confirmation on the page.
• Invitations by link. An organizer can invite family or a paid caregiver. The link expires after 14 days and can be revoked, and accepting it makes a membership.
• A real database. Everything is saved in Postgres with committed migrations. A developer can run it on a scratch local database with no credentials and no cloud account.
• One set of rules for every screen. The roles and visibility rules live in one shared package with no web framework in it, so a future mobile app would use them unchanged.
• Made for older readers and for phones: a 17px base type size, generous focus rings, dark mode, zoom support and a skip link.
• A labeled “Viewing as” switcher. A demo viewer can see the same screens as each role. It is fake sign-in, kept on purpose for demos, and it must never reach real people’s data.

Two calls on the stack went against my own precedent. For the mobile build, which is specified but not built, I chose Expo and React Native over the native SwiftUI I use for DeHoardMe. The permission model must not be rewritten in a second language, and I expect this audience to use Android far more than DeHoardMe’s does. And Lantern is one repository, not split into a frontend and a backend the way 50RH is, so there is one copy of the permission model and no API to keep in sync between repositories.

Designed on paper and not built: a spec for the mobile build, locality and local providers, and voice. The voice research stopped at props for the interviews, with no code and no vendor account.

A walkthrough of a seeded demo family, made up for the demo, was recorded on 30 August 2026. This frame is its Circle page: each person’s role, and what they can see.

How fast

1. 11 AugA shared log, a task list and a who-sees-what page ran on demo data, with 33 permission tests.
2. 13 AugEntries saved in a real database, with tests that one family never sees another’s.
3. 28 AugOrganizers invite family and a caregiver by link, and replies keep their entry’s privacy.
4. 28 AugThe full tests and a production build run on every pull request.
5. 28 AugInterview plan written. Until the interviews happen, build nothing new.
6. 30 AugA second AI model reviews a change on request. It advises and never blocks a merge.
7. 30 SepVoice researched and kept to props for the interviews. No code, no vendor account.
8. 30 SepThe everyone-sees-it default is pinned by tests, not by the order of a list.

How it stays right

The family-private tier is the part that has to be defended. Five handling rules make it defensible: everyone in the circle is the default; the picker names the parent; each feed shows a count of the entries its reader cannot see; every member can read the who-sees-what table; and filtering happens in the data layer, so nothing a viewer may not see is sent to their browser. The count is there on purpose. It is the difference between a private tier and a secret one.

The checks behind it:

• Filtering was checked for each role against the raw HTML the server sends, not only against the page as drawn.
• Integration tests run against a real database that also holds a fully populated second family. A query that forgets the family boundary fails against real neighboring rows instead of passing by luck. There were 15 of them when the database landed, and the suite has grown since.
• A private item that is hidden and one that does not exist return the same error, so a caregiver cannot learn that a private task exists. A test pins the two messages equal.
• Two family members claiming the same task at once get one claimant and one clean error, not a silent overwrite.
• The visibility chain is tested as a rule that must always hold, not only by examples, so adding a tier in the wrong place fails the tests.
• In September, the everyone-sees-it default turned out to rest on the order of a list rather than on the documented setting. It now reads the setting, two tests pin it for every role, and the server output checked afterward was unchanged.

And the way the work is run:

• Type checks, lint, the full test suite on a scratch database and the production build run on every pull request and on main. They have passed on every pull request since they were added.
• Every change after the first day has landed through a pull request, by practice rather than a setting that forces it: 10 merged, read 5 October 2026.
• As of 5 October 2026 there are 95 tests across three workspaces, and all of them passed on the last merged change.
• The voice research had three independent reviews before it merged. The privacy review caught two places where the design contradicted the product’s own privacy rules, and both were fixed.
• The roadmap has an honesty rule: a checked item means merged and working, not merely written.
• Some lines are written down so the product does not drift over them: no marketplace, lead generation or referral fees; no public ratings written by families; no automatic booking. Nothing in it is a medical record, and it should not become one.
• I have kept my own rule. Since the interview plan merged, the only work merged has been automated checks, documents and one fix to an existing rule. No new feature.

Some security decisions for real data are still open.