We started building what is now Brinn in August 2025, under the earlier name Memolink. The first version was a fairly conventional app: entries, people and categories, with a web client and an API. Since then the product has been renamed, restructured and extended across several surfaces.
Looking back at that arc, a few of our early assumptions about long-term memory didn't hold up. This post is an honest list of the lessons, not a postmortem of any single failure.
1. We framed memory as a journal
For a while, the place where captured information lived was called a "Journal". It sounded natural, but it quietly told users what the product was for: writing diary-like entries on purpose.
That's not how people use memory. They fire off a voice note while walking, forward an email, jot a half-sentence. In 2026 we renamed Journal to Memories across the product, and the framing change mattered more than we expected. Names set expectations about effort.
Lesson: the vocabulary of your product decides how much work users think they're signing up for.
2. We thought of "the app" as the product
The earliest versions were centred on a web client. But the moments when people need to remember something rarely happen inside a web app. They happen in a chat thread, an inbox, a browser tab.
That pushed us toward being present where people already are: messaging, email, web, desktop and a browser extension, all backed by the same memory. We wrote about the practical side in which Brinn surface suits which job.
Lesson: memory should follow the person, not the interface.
3. We treated storage as the hard part
It's easy to assume the difficulty in AI memory is capacity. It isn't. The hard parts turned out to be capture with no friction, understanding dates and entities, retrieving the right thing, and following through with reminders. See why AI reminders misread relative dates for one example of how small errors undermine trust.
Lesson: a memory system is judged by what it surfaces at the right moment, not by what it holds.
4. We underestimated how much "forgetting" matters
More stored data isn't better data. Stale facts, duplicates and noise degrade retrieval. Good memory needs ways for newer information to supersede older, and for users to see and delete what's stored. We cover the user-side controls in how to delete your data from AI services.
Lesson: design the forgetting at the same time as the remembering.
5. We kept renaming things
Memolink became Brinn. Journal became Memories. Pieces of the stack were reorganised into a monorepo with shared API contracts. Each change was reasonable on its own, but the cumulative churn has a cost for users, docs and ourselves.
Lesson: get naming and structure as right as you can early, and treat renames as expensive.
Where this leaves us
None of these were catastrophic, and we're still learning. But if you're building a personal AI, we'd suggest asking early: what does our wording imply, where do users actually need us, and what does the system do when information changes?
We're applying these lessons in Brinn, a personal AI for reminders, lists and memory across WhatsApp, email, web and desktop. What would you add to the list?
Top comments (0)