Building in public
You explain your deploy setup to your assistant. It helps. Tomorrow you explain the same setup again. And the day after. You are not training it. You are re-typing.
The tool nobody asked for
I did not set out to build a product. I set out to stop repeating myself.
My setup is four servers with names that mean nothing to anyone else, a tunnel with a numbering scheme I keep getting wrong, and a dozen small traps that only exist because of decisions I made two years ago. Every new session started from zero.
So I gave the assistant a place to write things down, and a way to read them back before it started working. Two calls: one to save what was learned, one to recall it. That was the whole idea.
For six weeks it had exactly one user. Nobody else could have used it, because I had not written a single line of documentation.
Six weeks of being my own only customer
That stretch turned out to be the most valuable part, and not because of what got built. Because of what got measured.
When you are the only user, every rough edge lands on you within a day. A recall that returns the wrong thing costs you the next hour. A save that silently drops a field costs you the next week, when you go looking for it.
I kept a count of the times the memory actually prevented a mistake. Not a feeling, a count. After six weeks it was high enough that I stopped arguing with myself about whether the thing was worth the effort.
The uncomfortable part: several of those saved lessons were about mistakes I had already made twice. The tool did not make me smarter. It made me stop paying for the same lesson.
The moment it stopped being a personal tool
The thought that changed it was not a market analysis. It was smaller and more honest: if I find this useful, and my setup is not special, then somebody else is retyping their own servers right now.
That is a weak argument on its own. Plenty of internal tools are useful precisely because they fit one person. So I looked for the part that was not about me.
What was not about me: the shape of the problem. Every assistant starts each session with no history. Every developer has context that lives in their head and nowhere a machine can read. That is not my setup. That is the default.
So I wrote the documentation I had skipped, then the onboarding I had never needed, then the parts that only matter when the user is not the author: error messages that explain themselves, a health check, a way to see what the thing actually knows.
What building for one user taught me about building for many
Three things carried over, and one did not.
Carried over: every feature had already survived daily use before a stranger saw it. There was no backlog of ideas nobody had tried. The roughest paths had been walked hundreds of times by someone who could not file a ticket and walk away.
Also carried over: the honesty. When your only user is you, a green checkmark that hides a failure costs you personally, so you stop building those. That habit turned out to be the actual product.
Did not carry over: my tolerance for silence. I knew what an empty result meant. A new user reads an empty result as a broken tool. Half the work of turning it into a product was teaching it to say why nothing came back.
Do this before you decide your internal tool is a product
You do not need my stack for any of this. You need a number and a stranger.
First, count the saves. Instrument your internal tool so it records every time it prevented rework. Not usage, prevention. Usage tells you it runs; prevention tells you it earns.
Second, hand it to one person who did not build it, with no explanation, and watch where they stop. That is your documentation backlog, in priority order, for free.
Third, read your own error messages as if you had never seen the code. Every message that says what happened but not what to do next is a support ticket you have already written.
A quick way to get the count without touching your tool's logic:
# Wrap the recall path and log whether it actually returned something useful.
# Two files, no dependencies, works with any tool that shells out.
log=~/.mytool/prevented.log
recall() {
out=$(mytool recall "$1")
if [ -n "$out" ]; then
printf '%s\tHIT\t%s\n' "$(date -u +%FT%TZ)" "$1" >> "$log"
else
printf '%s\tMISS\t%s\n' "$(date -u +%FT%TZ)" "$1" >> "$log"
fi
printf '%s\n' "$out"
}
# After two weeks, the ratio is your answer:
# awk -F'\t' '{n[$2]++} END {for (k in n) print k, n[k]}' "$log"
If the hit ratio is low, you do not have a product yet. You have a habit that has not paid off. That is worth knowing before you write the landing page.
What changes for you
Before: you open a session, explain your setup, get help, close the session, and the explanation dies with it. Tomorrow the same explanation, in the same words, because you wrote them once and nobody kept them.
After: the explanation is written down once by the assistant itself, and read back before the next task starts. You notice it not as a feature but as an absence — the absence of that first ten minutes.
Our version of this is cachly: the assistant saves what it learned after a fix and recalls it before the next task, over MCP, so the memory survives restarts, model upgrades and switching editors.
An internal tool becomes a product the day you can prove it earns its keep for somebody who did not build it. Until then it is a habit with a README.
I build cachly — memory for AI coding assistants, over MCP.
ChatGPT and Claude remember your conversations. cachly remembers your system: the bug you fixed, why you chose Postgres, the deploy step that always breaks — and which decision it contradicts. Every assistant you use reads the same memory, and every lesson carries the name of whoever learned it, so nobody from your team has to learn it twice.
Free tier, hosted in the EU: cachly.dev
