Technology
This page describes the working Genacy application as it stands in September 2026. Every statement here comes from the production code, not from a design document. Where something is planned but not built, the roadmap says so plainly.
A simplified view of the application. Access rules decide what can be returned.
The browser sends your signed-in request.
The service receives the request through one interface.
PostgreSQL enforces access to your records.
Claude composes a reply grounded in recorded memories.
Genacy is a web application. The part that runs in your browser is written in plain JavaScript with no framework, which keeps it fast and keeps the number of moving parts low. It talks to a single back-end service over one well-defined interface, and that service owns the database.
There is no second front door. Every request the app makes goes through the same client, carries the same kind of signed token, and gets back either data or a structured error that says exactly what went wrong. Long answers from a twin arrive as a live stream, so you see the reply forming rather than waiting for it to finish.
Nothing on the page is loaded from someone else's server. The libraries the app needs are served from Genacy itself and pinned to an exact version, and a check in the build refuses to merge code that reaches out to an external address. That is unusual, and it is deliberate: a page that loads a script from elsewhere is trusting whoever controls it.
Anthropic's Claude is the only large language model in the product. It is not one assistant doing everything — it is a set of narrow jobs, each with its own limits, because a model that can do anything can also do the wrong thing.
When you or your family talk to a twin, a larger model composes the reply using that person's own recorded memories as its material. It is not asked to imagine someone. If the memories do not cover it, the honest answer is that it does not know.
Your entries, recordings and imported documents are read and organised so the twin can find the right memory at the right moment, and so the interview knows which questions are still worth asking.
Spoken commands are turned into one of the actions the app already permits, and the app checks that choice against its own list before doing anything. The model can only ever point at a capability you already had.
Figures are built from trusted, largely public-domain sources into a knowledge base for each person, with what they could have known in their lifetime kept separate from what they could not. Fourteen figures have full knowledge bases today.
News and prompts are gathered and matched to what you care about. Nobody bids to put something in front of you.
Comments are scored and put in front of a person with a reason attached. A human keeps, hides, removes or blocks. The AI never removes anything by itself.
The model proposes. The application decides. That separation is what stops a spoken command becoming an instruction the app was never designed to follow.
Design rule, enforced in the voice codeAlongside the product, a set of AI agents runs over the codebase itself: checking the database schema has not drifted from the code, that the login and permission posture has not weakened, that the app and the interface still agree, that nothing has started fetching code from the open internet, that a self-hosted library has not been tampered with, and that the voice command map matches what the app can actually do.
These run before a change is allowed to land. They are the reason one person can move this fast without the usual consequence of one person moving this fast.
Nine of those agents are pass-or-fail gates on every change. Add hundreds of automated tests and a four-level review, and most classes of mistake never reach the application at all.
Saying "Hey Genacy" wakes the app. The listening for that phrase happens entirely on your own device, inside the page, using small open-source models. Ambient audio never leaves the machine, and the feature is off until you turn it on.
Once you are speaking a command, your browser's own speech recognition turns it into text, and the app tells you plainly which service that is before you agree. Replies are spoken with your browser's voice today. A cloned voice for your own twin is not built yet, and the app says so where it matters.
One rule overrides everything else in the voice system: it never captures a secret. On a password or two-factor screen, voice stands down and hands you back to the keyboard.
An on-device model listens for the wake phrase. Needs several confirming frames before it triggers, to avoid false wakes.
Your browser's speech service turns speech into text, with the consent screen naming which service that is.
The text goes to a small Claude model that picks one of the app's known actions. If it takes too long, an offline word-match takes over.
The app re-checks the chosen action against its own permitted list, then performs it. Secrets are never spoken.
Being straight about one detail: the wake-word model in place today is a stock open-source model standing in while a custom "Hey Genacy" model is trained. It works; it is just not ours yet.
The hardest things in this product are the ones that cannot be undone. That is where the controls are concentrated.
Passwords must be at least 14 characters with mixed character types, and are never silently trimmed. Time-based two-factor codes are supported and the app walks you through enrolling.
Irreversible actions require a fresh two-factor challenge at the moment you take them, which mints a single-use permission. An old session is not enough.
Each guardian gets only the specific permissions you grant, such as confirming a passing, managing boundaries or approving access requests. They have no window into your private content while you are alive.
Winding a twin down needs guardian agreement and a thirty-day waiting period. The system is built so that guardians retire a twin; they do not erase a person.
Access rules live in the database itself through row-level security. Someone who is not a moderator does not get a filtered queue, they get an empty one. The server returns a refusal even if the interface is bypassed.
Significant events, including confirming or cancelling a death report and changing a release instruction, are recorded and visible to you.
You can pause your account, request a download of your data, delete a twin, or delete the account entirely through a deliberate two-step process.
Every piece of user-supplied text is escaped before it is displayed, and the code uses text-only interfaces rather than markup sinks. This is the discipline that prevents one family member's post from attacking another's browser.
The application has hundreds of automated tests, organised into 37 suites that run in a simulated browser, covering authentication, twins, memories, people and guardians, the death flow, moderation, voice, wake word, tiers, imports, interviews and the admin tools. On top of those sit 22 end-to-end specs that drive a real browser, including accessibility checks and visual comparison against reference images.
Nine further checks gate a change before it can land. They look for database schema drift, weakened authentication posture, drift between the app and the API contract, any attempt to fetch code from an external address, tampering with a self-hosted library, and mismatches in the voice action map.
The reason for all of this is a specific scar. Early in the build, a bug sat in the code while every test stayed green, because every test entered through a side door and the front door was the thing that was broken. The rule that came out of it is on the How we build page, and it governs the project: passing tests are evidence the tests pass. They are not evidence the code works.
Structure — does it parse, balance and count correctly?
Function — trace every path end to end, including the cold start nobody tests.
Content — compare against the original to prove nothing was lost.
Render — load it in a real document and verify what a person would actually see.
Seven dollars in every ten are spent checking the work, not producing it. That ratio is a choice, and it is the single biggest reason this build has held together.
Validating and testing 70%Writing the code 30%
Writing code with AI is the cheap part, and getting cheaper. Being sure it is right is the expensive part, and it does not get cheaper on its own. Spending the budget this way is slower on any given day and far faster over a month, because the work that has to be torn out and redone is the thing that actually costs you. The alternative is a build that looks fast right up until the point it collapses.
Genacy Labs, founder's own measure of AI spend across the build, September 2026.
| Share | |
|---|---|
| Validating and testing | 70% |
| Writing the code | 30% |
Coming soon · First 2,000 trial users only
Help shape Genacy and keep the early-member benefit for life.
Join the beta trial