I spent two years building things nobody used. This time I'm stopping at v0.2.0.
Over the last two years, I've built a lot of things.
Developer tools. CLIs. SaaS products. Automation tools.
Most of them followed roughly the same pattern:
I found a problem.
I started building.
I saw more things that could be improved.
I added them.
The project became bigger.
I polished the architecture.
I added another feature.
And somewhere along the way, I forgot the most important question:
Does anyone actually want this?
The uncomfortable answer for several of my projects was: I didn't know.
I had spent months answering engineering questions before answering the product question.
So I'm trying something different with my latest open-source project.
It's called Recall.
I built it because I kept seeing coding agents repeat the same repository exploration across sessions — reading package files, finding entry points, exploring folders and rediscovering conventions.
Recall generates persistent repository context locally and deterministically, so that context can be reused across Claude Code, Codex, Cursor or any agent that can read Markdown.
No AI API is required.
I released v0.2.0.
And now I'm stopping.
Not abandoning it.
Stopping feature development.
My engineering brain already has a list:
MCP integration
editor plugins
semantic analysis
more languages
team features
better repository intelligence
I'm not building any of them yet.
For the next 30 days, the product roadmap is basically empty.
Instead, I want to answer a few boring but much more important questions:
Will developers actually install it?
Does it reduce repository exploration on real tasks?
Does someone who uses it once choose to use it again?
I'm measuring things like time to first correct edit, exploration time, tool calls and repeat usage.
If the answer is no, adding another six months of features won't rescue the idea.
And if the answer is yes, I'll know what deserves investment based on actual usage rather than my imagination.
This is surprisingly uncomfortable as an engineer.
Building another feature feels productive.
Waiting for evidence doesn't.
But after spending too much time building products before validating whether anybody cared, I think this is the discipline I was missing.
Recall is here:
https://github.com/sabahattink/Recall
You can try it with:
npx recall-context@latest init
I'm especially interested in hearing from other technical founders:
How do you decide when to stop building and force yourself into validation mode?
And if you've killed a technically good product because usage never appeared, I'd be interested in that story too.
The mechanism that finally worked for me: write the verdict rule before the window opens, not during it. A date, a number, and the three branches (continue / iterate one lever / kill) on paper before launch. Stopping stops being a daily willpower question — you pre-decided it once, and the discomfort compresses into the single moment of writing the rule instead of thirty days of re-litigating it with yourself.
One addition to your measurement list, learned from a post-mortem elsewhere on this site: pre-commit a denominator too. "Does someone who uses it once use it again" can only be answered if enough people use it once — decide now what N installs makes the test valid. Otherwise the honest day-30 verdict might be "the test didn't run" rather than yes or no, and those need different responses: thin reach means fix distribution and re-run; real reach with no retention is the actual no.
I'm mid-window on exactly this discipline right now (paid product, pre-registered thresholds, day 4 of 7) and can confirm the itch you describe: every quiet day, "build another feature" whispers that it's the productive choice. The pre-registration is the only thing I've found that keeps the quiet days from quietly redefining the test.
I completely relate to this. As a developer, it's so easy to fall into the trap of over-engineering the architecture and over-polishing the UI before validating the market. For my current project, I intentionally went with a bare-bones, terminal-style dashboard with high information density. No empty space, no fancy animations—just the raw historical data needed to expose fake e-commerce discounts. Stopping at a functional MVP is a superpower if it means you get user feedback faster. Keep shipping!
Yep, that’s exactly the trap I’m trying to avoid this time. Building is the comfortable part — stopping and waiting for real feedback is much harder 😄
ohh this seems quite cool mate. Best of Luck. Also tell me if you've figured out a way to rapidly find your first users for that loop.
Thanks mate! Still figuring that one out 😄 Finding the first real users is probably harder than building the thing. If I crack it, I’ll definitely share what worked.
But, how would you measure in the first place unless you know something using it and letting you know something can be made better?
Exactly — that’s the constraint.
I can’t measure repeat usage from anonymous npm downloads if Recall has no telemetry and the user never talks to me.
So for this first validation phase, I’m not treating every download as part of the experiment. I’m recruiting a small group of users who explicitly agree to test Recall on real coding tasks and report what happened.
That gives me a smaller dataset, but one I can actually trust.
Public downloads are acquisition. The validation cohort is measurement.
If I can’t even find 10 developers willing to use it and report back, that’s useful evidence by itself.
The harder question comes later: if it passes that stage, how do I measure retention in a local-first CLI without violating the reason people may trust it in the first place?
I don’t have a good answer to that yet.
How are you currently measuring activation and repeat usage for Recall?
Right now, imperfectly — and that’s a gap in the validation setup.
Recall itself has no usage telemetry, so npm downloads can’t tell me activation or retention. I don’t want to quietly add tracking just to make the metrics easier, especially for a tool positioned as local-first.
For this validation period I’m treating:
Activation as an external user successfully running Recall on a real repository and actually using the generated context in a coding-agent task.
Repeat usage as that same user choosing to use Recall again in a later coding session without me prompting them to.
I’m tracking those through a small cohort of external testers and session-level validation records, rather than inferring them from downloads or stars.
npm downloads, GitHub traffic/stars, and article engagement are acquisition signals only — not activation.
The weakness is obvious: this doesn’t scale and it relies partly on self-reporting. But for the first 10–30 users I’d rather have high-confidence manual evidence than add product telemetry before I know the product deserves it.
If Recall gets past this validation stage, privacy-preserving measurement is something I’ll have to solve properly.
Curious how you’d approach that for a local-first CLI without turning telemetry into part of the trust problem.
That makes sense. I’d avoid adding traditional telemetry too if “local-first” is part of the trust proposition.
One approach could be a privacy-preserving validation layer that only records anonymous product events/aggregates (e.g. activation completed, context used, repeat session), without sending repository contents, prompts, or code.
If you’re interested, I’d be happy to discuss how I’d structure it. Where’s the best place to reach you?
Stopping at v0.2.0 only helps if you've also decided what would make you continue. Otherwise the rule just relocates the failure — two years of overbuilding one thing becomes several years of abandoning things at v0.2.0, and both look like discipline from the inside.
The version number isn't the signal. What's the observation that would tell you to keep going?
That’s a fair criticism — and it’s exactly why I set the continuation criteria before launching.
v0.2.0 isn’t the success condition. It’s just where I stopped adding variables.
The observation I’m looking for is this:
Across at least 30 real external coding sessions, Recall should reduce median time-to-first-correct-edit by at least 25% versus the native agent workflow, without materially hurting correctness, and reduce tool calls or context usage by at least 15%.
I also want to see repeat behavior: at least 30% of users coming back for 3+ sessions within 30 days.
If I can’t get at least 5 external users to use it repeatedly, or the measured time improvement stays below 10%, I archive it.
So the rule isn’t “stop at v0.2.0.”
It’s:
freeze the implementation, define the evidence before seeing the results, then let the evidence decide whether v0.3.0 deserves to exist.
Your point about serial abandonment is important, though. A freeze without a precommitted continuation condition can absolutely become another way to avoid making the hard decision.
What's missing from the discipline question: for people who don't write code themselves, the cost that normally forces a stop, running out of hours or hitting your own skill ceiling, doesn't exist the same way. I direct Claude to build Alisio, and a new feature can go from idea to shipped in an afternoon. That makes the 30-day freeze harder to hold, not easier, because nothing about the process signals "this is expensive, be careful." The gate I ended up needing wasn't time-based, it was a rule: no new feature ships until I can name the specific decision a real user made wrong without it. Not "would be nice", not "competitors have it", a decision. Most weeks nothing clears that bar, which is uncomfortable when building feels so cheap and fast. I don't have usage data yet to know if it's working. I only know it stopped me from shipping things I couldn't defend.
This is probably the strongest challenge to the 30-day rule I’ve heard so far.
You’re right: when implementation becomes cheap, cost stops being a useful constraint. And for someone who can direct coding agents all day, “I can build this by tonight” is almost the worst possible justification for building it.
Your decision rule is much stronger:
What specific decision did a real user make wrong because this feature didn’t exist?
I like that because it changes the burden of proof. The default becomes “don’t build it,” and the feature has to earn its way into the product through observed behavior rather than possibility.
I’m going to keep the 30-day freeze for Recall because I need a clean validation period, but I think the more important question is what happens on day 31.
A time-based freeze ends.
A decision-based gate doesn’t.
I may adopt exactly that rule after the validation period: no feature gets built unless I can connect it to an observed user failure, repeated friction, or measurable outcome.
And your last sentence is important too. You don’t need usage data yet to prove the rule improves the product. At minimum, you’ve already proven that it prevents features you can’t defend.
I’d be interested to hear more about Alisio and how you’re documenting those rejected feature ideas rather than losing them.
The lesson of stopping at v0.2 instead of spending months building every possible feature is probably one of the hardest ones to learn as a founder. Getting something in front of users early gives you information that weeks of building just can't.
It's tempting to keep polishing because building feels productive, but user feedback is usually where you find out what actually matters.
Exactly. That’s the habit I’m trying to break.
The dangerous part is that polishing genuinely feels like progress — especially when you’re an engineer and there’s always something obvious to improve.
With Recall I’m deliberately leaving a list of things unfinished until actual usage tells me which of them matter.
I’m curious: when you validate an early product, what’s the strongest signal for you — people trying it once, coming back to use it again, or actually paying?
The hardest part is probably resisting the urge to interpret silence as a reason to build more. Giving yourself 30 days where usage is the only thing that can change the roadmap seems like a pretty good forcing function.
That's exactly the part I'm trying to force myself to do differently this time.
My default response to silence has always been “the product needs one more feature.”
With Recall, I've frozen feature development at v0.2.0. For the next 30 days, usage is the only thing allowed to change the roadmap.
I'm especially interested in one signal: not whether someone stars it, but whether they use it again on a second coding session.
If that doesn't happen, I think the answer is pretty clear.
Have you ever actually killed one of your own products after a validation period like this?
That makes sense. I’d be interested in continuing the conversation by email if you’re open to it. What’s the best email to reach you on?
Absolutely. Happy to continue the conversation.
I’m particularly interested in getting an outside perspective on the validation approach and, if Recall is relevant to your workflow, hearing what happens when you actually try it on a real repository.
I’ll reach out privately so we don’t have to post email addresses here.
Sounds good — you can reach me at [email protected]. I’ll keep an eye out.