In development

Childhood Archive

A private living archive for childhood photos, voice, stories and family context — designed so AI can organise memories without becoming the authority on them.

Preserve the photos and the stories behind them, while keeping originals portable, family context human-owned, and every privacy or backup claim evidence-backed.

The problem

My phone has years of photos and videos of my daughter. The problem is not taking enough pictures. It is knowing that the important moments can still disappear inside a camera roll — or survive as files while the story behind them gets forgotten.

At the same time, when I ask my dad for photographs from my own childhood, there is effectively nothing to pull out and revisit. Those two problems look opposite — too many photos versus too few — but they point at the same thing: taking a picture is not the same as preserving a childhood.

Childhood Archive is my attempt to solve that properly.

Their childhood goes faster than your camera roll can keep up. Keep the photos. Keep the stories behind them.

What I am building

The product is a private family archive for original photos, video, voice recordings, quotes, letters and the context a camera cannot know. The interface is meant to feel closer to a living family album than a file manager or generic AI dashboard.

The core experiences are being built around a few simple jobs:

  • preserve exact original media rather than destructively rewriting it;
  • turn a large camera roll into a navigable childhood timeline;
  • let a parent add the meaning behind a photograph by text or voice;
  • remember the people, sayings, routines and little details that normally disappear;
  • revisit a small set of memories together through a calm Tonight's Memories ritual;
  • export the archive so it can outlive one app, AI model or storage provider.

The important AI rule

The project has one product principle I keep coming back to:

AI organises the memories. You tell the story.

A model can observe that a child appears to be smiling. It cannot decide that it was "the best day ever." It can suggest that two faces may be the same person; it cannot silently declare the relationship. That distinction is now encoded as three provenance layers:

  1. Observed — machine or metadata inference;
  2. Known — something a family member supplied or explicitly confirmed;
  3. Written — optional narrative built from traceable evidence.

AI output is treated as replaceable derived data. Original media and human-authored context are the archive.

Trust before growth

This is deliberately not a public signup product yet.

The current web experience runs on fictional sample media while the private archive substrate is being proven. Before real family media is accepted, the system needs live evidence for authentication, family isolation, private object access, integrity checks, export/restore, destructive-action recovery and operational privacy.

A successful upload is not called a backup. A safe to delete from your phone state will require a current integrity check of the primary original plus a verified independent replica. Sensitive memories are excluded from automatic resurfacing by default. The archive preview itself is kept out of search indexes; public marketing and private family data are separate surfaces.

Where it is going

The shipping destination is broader than the current web prototype:

  • personal production — a private archive I can genuinely rely on with my daughter;
  • public web — a By JTT product site explaining the problem, trust model and product without exposing family archives;
  • native private beta — a first-class Expo / React Native iOS and Android client with selected-photo access, voice capture, offline-safe queues and resumable uploads;
  • public stores — App Store and Google Play releases only after the privacy, account-deletion, recovery, support and store-review requirements match the real implementation.

The native app does not exist yet, and I am documenting that plainly rather than presenting roadmap work as shipped functionality.

Why I am documenting it now

This is intended to become a longitudinal By JTT case study rather than a polished story written after launch. The useful evidence is the messy part: architecture decisions, privacy gates, things the prototype got wrong, failed assumptions, real-world camera-roll edge cases, restore tests, device testing and what changes once the product is used repeatedly rather than demonstrated once.

The first milestone is not "get users." It is make one childhood genuinely safer and easier to revisit without lying about what the software can guarantee.