May 31, 2026
Two-Factor Auth for a Memory Only I Use
Four months building a multi-user memory platform for a team of one. Now I am shutting it down.
30 epics. 185 commits. Four months. I built a server that gives an AI assistant long-term memory: a place where it remembers facts instead of forgetting them after every conversation. mmcp.dev. Exactly one human ever used it: me.
Now I’m shutting it down.
The idea was good
AI assistants have no memory. Every conversation starts from zero. Today I tell Claude how I work, what I’m building, what I decided last week, and tomorrow it’s all gone. The same round of introductions every day.
I wanted to fix that. A memory that lives outside the assistant, one that several tools can plug into: Claude at the desk, an agent in the terminal, an app on the go, all drawing from the same store. You tell it once, it stays. There’s an open standard for exactly this, MCP, the protocol AI tools use to plug into data sources. Memory plus MCP, so mmcp. The name was there in ten seconds.
Then the thought the whole rest grew out of: if one person can share their knowledge this way, why not a team? A shared memory for a group. My knowledge, your knowledge, the shared knowledge, cleanly separated and still connected. Every colleague’s assistant knows what the team knows.
A reasonable idea. A real, everyday frustration. Up to here, all correct.
The team that never came
The moment “team” was in the plan, everything suddenly made sense. Multiple users need separate spaces. Separate spaces need access control. Shared knowledge should be groupable. Anyone managing other people’s knowledge needs proper logins, ideally with a second factor. And when a company dumps its data in, it wants to hold the keys itself.
Every one of these features is right. For a team. That’s exactly the trap: the vision justifies the effort cleanly, step by step, every step logical. I planned a complete multi-user platform, honestly convinced the team was about to show up.
The team never came. It stayed at one user. Me. I built the whole machinery for a group of exactly one person.
Why nothing put on the brakes
How I build is laid out in detail here: design it, spec it, let the AI execute. That’s also where I described the basic pattern: with AI you plan too much, and while building you cut most of it back out. With navigator that worked. Live data gone, almost all languages gone, a lean thing in the end. mmcp is the opposite case. Reality knocked just the same. I just didn’t open the door. Two brakes were unhooked.
The first is the price per feature, and the trick is: no single feature was expensive. Two-factor auth, with an off-the-shelf building block, takes hours, not days. Each “yes” on its own was cheap and defensible. That’s exactly where the poison sits. Building used to mean typing it all out a hundred times yourself, and by the thirtieth you ask whether you really need this. The brake was never my discipline. The brake was the sum of a hundred small yeses. With AI each “yes” costs one sentence and one coffee. You never feel the sum. You say yes a hundred times and at the hundredth you don’t notice ninety were too many.
The second brake hangs on the plan itself. My method produces complete documents. A product concept, an architecture, a list of thirty-five numbered requirements. Looks like a product with a team behind it. Behind it stood me. Alone. And everything the document names but doesn’t yet exist looks like unfinished work, not a deliberate limit. So you build it. Point by point. The document pushes, not the AI.
The finest proof is in my own encryption concept. I wrote a section called “Out of scope” and carefully listed what I was deliberately leaving out. Among it: encryption that keeps data sealed in memory even during processing, state of the art by 2028 at the earliest. For the team that was supposed to come any day. Anyone who writes a list of what he deliberately does NOT build is no longer planning for himself. He’s planning for a company in his head. I formatted the list nicely.
The feature graveyard
Eight work packages for my own login. Read the sentence again, then comes the rest.
All built, all tested, all for one user:
- Two-factor auth. TOTP, QR code, ten recovery codes. And org admins can force two-factor on their employees. For a login with exactly one person behind it. I secured myself against myself.
- A knowledge graph. The system notices on its own when two of my notes contradict each other and links them into a clickable web of cause and effect. I can’t even pin this one on the team. Pure self-indulgence: I wanted to know whether my shopping list was internally consistent.
- A self-learning trust model. Over time the system learns which facts it can believe blindly, measured against its reviewer’s ratings. The reviewer was me. Only me. Always me.
- Customer-controlled encryption. Eleven work packages, a roadmap across four to five months, external key services, an encryption scheme modeled on 1Password and Signal. Customer-controlled. For a tool with one customer. Guess which one.
On top of that: organizations, an industry-standard login system, and the ability to bundle several strictly separated data pools. Strict data separation. For a single human who owns all the pools.
The moment I almost caught it
In that very encryption concept there’s one line that shows everything. I cut an external security audit, reason: too expensive for a private project, five to fifteen thousand euros. We’ll do it once the first real customer arrives.
There I had the brake in my hand. I saw that a five-figure audit for my hobby is absurd. And in the same document left eleven work packages for customer-controlled encryption standing. I cut the one absurd line and didn’t touch the other four hundred. The brake was right there. I tapped it once, briefly, then kept building.
Whose mistake this was
Important: this was no weakness of the machine. The AI built exactly what the plan said. Clean, tested, reviewed. When I write down “customer-controlled encryption, five phases, own key service”, it’s not its job to ask whether I’ve still got all my marbles.
It was my plan. My imagined group. My missing brake. The discipline that vanished effort used to force now had to come from me. It didn’t.
I’m no security specialist, I’ve admitted that elsewhere. Here the limit gets concrete: a real architect’s value isn’t building the encryption more cleanly. It’s the sentence “you don’t build that at all, not for a team that doesn’t exist”. I didn’t have that voice. The AI isn’t it. It lowers the price, it doesn’t draw a line.
I’m not alone in this. Charlie Holland nails it in Claude is not your architect: the AI can’t do the one thing that makes an architect valuable, namely say no. It builds what you ask for and validates the idea while it’s at it. Engineers design, agents implement. With mmcp I filled both roles and slept through the first.
The end
mmcp is getting shut down. My notes are moving into a Notion. Out of the box it does exactly what I actually needed: write text in, search over it, the assistant reads along through a ready-made connector. One checkbox, done. No cluster, no key service, no recovery code. The server gets cancelled.
That doesn’t hurt. I build a lot and shut down what doesn’t hold. What’s left is a question I now ask before every single story: who besides me needs this, today, not in the conditional? If the answer is “nobody”, I don’t build it. Sounds cheap. Would have saved me four months.
The lesson behind it is uncomfortable: good plans and cheap building are no virtues when the brake is missing. They’re an accelerator in the wrong direction.
The AI built. I overbuilt.