I spent two years building things nobody used. This time I'm stopping at v0.2.0.

The freeze is the easy half. The harder problem with "no telemetry, just talk to the first users" is that it cannot separate two very different answers: the premise is wrong, or they never got far enough to have an opinion about the premise.

I hit this constantly on my own product. I'm the founder of Lisar Connect, a VPN service, and our deliberate scope cut was not shipping an app of our own at all — you import a connection profile into a standard client. That removed a large amount of engineering, and it moved the entire first-run experience into documentation. The first useful signal was never what people thought of the idea. It was which documented step they stopped at.

For Recall I would write the first run down as an ordered list before day one: installed, ran it in a repo they actually work in, agent consumed the output, completed one real task with it. Then for each of your first users, record the last step they completed. That is a line in your notes, not telemetry.

It turns the 30 days into two separate results instead of one blurry one. A "no" that arrives after step four is a real answer about demand. A "no" that arrives at step one or two is an answer about packaging, and it is worth fixing before the remaining days start counting it as evidence.

I really needed to read this today.Most freelancers lose money in the gap between managing a project and actually invoicing for it. I'm building a single workspace to close that gap, and it is so easy to fall into the trap of over-polishing before anyone has even tried it. Launching at v0.2.0 sounds terrifying, but it's clearly the right move. Thanks for the reality check!

The freeze gets much easier to hold if you write the exit condition down now - something like "if fewer than X repos run init a second time in 30 days, I stop" - otherwise the temptation is to reinterpret flat usage as "it just needs MCP integration". For something distributed by npx, repeat usage is the metric I'd trust most: the first run is curiosity, the second run is the only real signal. One practical trick for the engineering itch: park the roadmap list somewhere visible, like GitHub issues with a "post-validation" label, so shelving those features feels like deferring them rather than losing them.

The good part is that the thing that you are building can be self-validated. Take Recall and fire up on different opensource projects that have issues pending. Pick a issue run two sessions, on two different branch/worktree - one with Recall and one without. For cleaner you can use Virtualbox or install Recall locally than globally and then run two sessions.
Build a session evals - to compare toolcalls and token usage. To validate if Recall makes the coding agents to use the context given by it, you can fire up third session to put that session as judge to evaluate who did the task more effectively.

Run this on combination of problems on the same repo or different repo. I think it will streamline your validation for v2.

The discipline of stopping at v0.2.0 to measure instead of imagining what’s needed next is the harder skill, and most engineers (me included) avoid it because building feels like progress and waiting doesn’t.
To your first question: for me it wasn’t a deliberate decision, it was forced — shipped CheCeno, kept building for months, and only stopped adding features when I ran out of obvious things to fix. In hindsight I should’ve forced the stop much earlier, right after the first working version, and spent that time figuring out if the core premise held up instead of polishing it.
To your second: not killed, but should have — I kept a positioning assumption alive for months that a five-minute conversation with a real user would’ve killed on day one. Nobody around me, including the AI I was building with, ever asked “does this actually need to exist as its own app.” It answered every technical question well. It never once asked the one that mattered.
Curious what “time to first correct edit” looks like so far, even directionally — is it close to what you hoped, or still too early to tell?

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.

I can really relate to this. Building the product is exciting, but getting people to actually discover and try it feels much harder. I'm learning that talking to users early is just as important as building.

The 30-day freeze becomes much stronger with precommitted evidence thresholds. Track install, successful initialization, first correct edit, repeat use on a second repository, and the number of qualified developers who actually saw the project. If reach is too low, the test did not run; if people install but never return, the value loop failed. Those are very different diagnoses.

Stopping at v0.2.0 is a massive superpower. Most builders spend years polishing a dashboard that nobody will ever log into.

Regarding finding your first users rapidly for this loop: the secret is to treat your distribution with the same iterative mindset as your code.

Instead of waiting for a big launch day, run tiny distribution experiments. Find 3 niche threads where people are actively struggling with the problem you solve. Offer a manual workaround in the comments. If they respond well, send them a DM with your v0.2.0 link.

This gives you a tight feedback loop with real users before you build anything else.

I got so frustrated watching builders fall into the multi-year development trap that I'm building Octoloops. It helps founders match their product stage to practical, zero-budget distribution channels so they don't have to guess.

What does your v0.2.0 product do? Let's brainstorm where those first 5 users are hiding.

Building really does give you a false sense of progress. It's like getting on a treadmill and say you're going to walk to the store.

I've run into the same problem with my own projects. There's always something you can work on, so it's easy to confuse having work to do with having a reason to do it.

What I like about your 30-day pause is that you're forcing yourself to sit with the uncertainty instead of immediately responding to it with another feature.

What's your plan if the evidence is mixed. Say a handful of developers use Recall more than once and clearly get value from it, but overall adoption stays low. Would that be enough evidence to keep investing in the product, or would you start questioning distribution before going back to the roadmap?

The hardest part is treating validation as a feature freeze instead of a marketing phase. I like using one falsifiable behavior metric before reopening the roadmap, for example: if 10 fresh installs do not produce at least 3 repeat uses inside a week, the next work is not features, it is either onboarding, positioning, or killing the idea.

It also helps to write down what evidence would make you stop. Otherwise every quiet launch turns into "maybe it just needs one more integration," which is exactly how the engineering loop wins again.

I have killed two this year, and the embarrassing detail is that both were finished and working. One was a Mac app I deleted the same day I discovered the incumbent was freeware — nobody pays a one-time price to compete with free, and a two-hour look at the competitor's pricing page before writing code would have told me that. The second one I built the same way and killed the same way, which taught me the real lesson: knowing the rule is not the same as following it when you are excited about an idea.

So my answer to "when do you force validation mode": before building, not after. Now I check what the incumbents actually charge today, verified on their sites, before I write a line. If the incumbent is free, there is no paid business there, full stop, no matter how much better my version would be.

And I can confirm your repeat-usage instinct from the other side: the one app of mine that survived now gets its entire roadmap from returning users. The last release had nine changes, all nine from user reports. When usage is real, you stop guessing what to build — the roadmap writes itself.

I've built 2 with 0 customers as well... On to the third... Maybe I am a masochist. My heart tells me it only takes 1!

The empty roadmap is useful, but I would add one more constraint: define what each result means before the 30 days begin.

For example, low installs may mean the distribution or positioning failed, while many first runs with no second use points more directly at weak recurring value. If those outcomes remain in one bucket, it becomes easy to interpret any disappointing result as “we just need more reach” or “we just need one more feature.”

I would track a short evidence chain: saw the problem, installed Recall, used it on a real repository, let an agent consume the context, returned for another task. Then decide in advance which broken link permits a product change and which one should make you reconsider the premise.

Stopping development creates space to learn. Predefining the decision rules makes it harder for engineering optimism to rewrite the lesson afterward.

The "30-day empty roadmap" is the constraint that forces clarity. Most founders ship features to feel productive because it delays the uncomfortable feedback: will anyone care? You're right that repeat usage is the real signal - initial adoption could just be curiosity, but someone returning to use it again means they solved a real problem. The fact that you're measuring time-to-first-edit and exploration time suggests you're building a feedback instrument, not just shipping code. That discipline of weaponizing your own skepticism about feature value is rare. Rooting for the 30-day experiment.

Stopping at v0.2.0 takes real discipline, especially when the engineering brain just wants to keep shipping. Tracking time-to-second-use manually is a brilliant move—unprompted repeat usage is the only metric that never lies. Rooting for the 30-day experiment!

I agree that stopping at v0.2.0 and allowing usage to determine future releases is a good idea. ~

When you start adding features, you start avoiding the harder question. What more can this do?“Is anyone actually coming back?” is much easier to answer.”.

I've noticed that repeat use is a much stronger signal than initial interest. A person's decision to try something once could mean curiosity. Returning typically suggests that it resolved an issue.

The most important part of this 30-page planning guide is probably the empty 30-day roadmap at the end. It provides enough room to see what users actually take out of the product instead of guessing what people will want next.

The v0.2.0 mindset is honestly underrated. Shipping something smaller, getting real users to interact with it, and learning from that feedback is often more valuable than spending another year building features nobody asked for.

The biggest lesson here is probably: build less, validate earlier, and let users decide what deserves to exist.

I relate to this so much. It feels like I’m reading a summary of several years of my own life: years that didn’t end all that long ago.

The turning point for me? Yet another technically brilliant product. But this time, when I finally put it in front of users (my first real round of customer interviews) the answer was basically:

“It’s good, but I don’t need it.”

That’s when I finally understood that my solution wasn’t the most important thing. The problem itself wasn’t either.

What ultimately matters is the intensity of the user’s pain.

And it has to be strong enough, because strangely enough, some users have simply learned to live with their pain.

Since then, I’ve adopted three rules:

1. I look for expressed user pain, rather than an interesting technical challenge to solve.
2. I validate adoption early: V0 + a small round of user interviews and feedback.
3. If there’s no traction, I put the project on standby unless I personally get value from using it, in which case it stays alive as a low-intensity dogfooding/maintenance project.

I’m still an engineer, so building is always more comfortable than validating. But at least now I try to build more useful things.

This is a fantastic shift in mindset! Recall actually sounds like a highly practical tool—reducing that repetitive context-gathering phase for coding agents is a real pain point. Forcing yourself to sit on an empty roadmap for 30 days just to watch the analytics (like time to first correct edit and repeat usage) takes serious discipline. Thanks for sharing this raw and honest experience.

Two years is a long runway to learn that lesson — respect for naming it plainly instead of spinning it. What’s different about how you’re deciding “this is done” at v0.2.0 versus what kept you building past the point of validation before?

ca compte vraiment

Stopping early at v0.2.0 is a huge mindset upgrade. What do you usually do with your old codebases? Leave them on GitHub or try to pass them on? I built an AI valuation tool at Digimarket to help founders quickly check if their abandoned side-projects have market value.

Stopping at v0.2.0 may be harder than building v0.3.0. While building DictaFlow, I've found that the useful roadmap ideas usually come from real failures in someone's workflow, not from my feature list. Your three questions are good, but I'd add one more: when someone stops using Recall, can you identify the exact moment it stopped earning its place? That answer will probably tell you more than another month of install counts.

"Building another feature feels productive. Waiting for evidence doesn't." — this is the exact tension I didn't have words for until I'd burned six months on things nobody validated.

The question I ended up using to force myself into validation mode: can I get 3 people to use this in the next 7 days without me explaining it? Not install it, not create an account — actually use it for a real task. If the answer is no, the product has a clarity or distribution problem that more features won't fix. If yes, I know the entry point works and I can find the next blocker.

The thing that helped kill the feature list in my head: reframe those engineering ideas as downstream problems. MCP integration and editor plugins are real — but they only matter if someone hits a wall using v0.2.0 and specifically asks for that. Build the list from friction evidence, not from your engineering brain's imagination. Right now you have zero user friction reports. That's the experiment, not a reason to add features.

What does success look like for you at the end of the 30 days? What number moves and you say it works?

the pattern you named, answering engineering questions for months before answering the product question, is THE trap, and naming it out loud is most of the fix. one gentle pushback though: stopping at v0.2.0 is a rule about scope, but scope wasnt really your problem, evidence was. a hard version cap just makes you fail faster if youre still not testing demand, youll ship ten tiny things nobody wanted instead of one big thing nobody wanted. the rule that actually would have saved those two years isnt "stop at v0.2.0", its "i dont get to build feature N+1 until someone actually uses feature N". tie every increment to a real person doing a real thing, not to a version number. the other trick that breaks the build-first reflex for engineers: force a yes BEFORE you write code, a pre-order, a paid pilot, a waitlist that actually converts, someone saying take my money. if you cant get a yes on the promise, the product wont create one. whats the v0.2.0 youre building now, and has anyone told you theyd pay for it yet?

Your 30 day pause is right, but I'd swap the time box for an evidence box. At Henson Venture Partners we gate deals at $1,000 MRR or 100 customers because a number forces honesty in a way a deadline doesn't. Pick your equivalent, say 50 developers who use Recall a second time, and let hitting or missing that number make the roadmap decision for you.

One experimental-design issue I’d watch with the “with Recall / without Recall” comparison is learning leakage between sessions.

If someone explores a repository without Recall first, both the developer and the agent workflow have effectively learned something about the repo before the Recall run. Reverse the order and Recall may accidentally give the baseline the same advantage.

For the first 10 testers, I’d try to make the comparison closer to a paired cold-start test:

use two comparable tasks or repository snapshots, reset the agent context between runs, and randomize which condition goes first.

I’d also define “correct first edit” mechanically where possible — passing tests or explicit acceptance criteria — rather than relying only on whether the developer felt the edit was correct.

One additional metric might be especially interesting:

break-even session.

Recall has an upfront cost to generate and maintain repository context. If it saves two minutes per task but costs five minutes initially, the important question may be whether the cumulative workflow becomes faster on session 2, 3, or 10.

That would let you answer something stronger than “Recall makes an individual task faster”:

“After N real coding sessions, maintaining repository context pays for itself.”

Have you thought about controlling for the learning effect when the same developer tests both conditions?

From 3 months of dogfooding my own devtool (amami.dev — AI-native analytics), the most honest signal I found isn't repeat usage per se, it's time-to-second-use. A second invocation days later, unprompted, means it earned a place in the workflow; no second use usually means the install-to-useful gap, not a dead premise. Freezing features for 30 days is right — just split "never got running" from "ran once, didn't stick".

:))

The repo context problem is real watching agents reexplore the same folder structure every session is exactly the kind of waste that's easy to shrug off until you actually measure it.

To your question: the thing that's worked for me isn't deciding to stop in the moment that's basically impossible once you're deep in engineering flow, the next feature always feels like the one that matters. What's worked is writing down what 'done' means before starting, so there's something to check against later instead of relying on willpower mid-project. You basically did that with v0.2.0, just retroactively, by writing this post and drawing the line now. Curious if you'll set the next checkpoint explicitly before the 30 days start, or figure it out again as you go."

This is a great reminder that building more features can sometimes be a way of avoiding the harder product question: “Does anyone actually need this?” I really like the 30-day pause on feature development and focusing on real usage instead. Curious to see what the usage data reveals about Recall.

Let me leave another response because this is a really good topic. I also believe the issue here is complete market saturation when it comes to applications. On Google Play and the Apple App Store, there are millions of apps. I think a new strategy is what it takes. Look at Google now with SEO; to me, that is dead on arrival now that Google has AI Mode. Everyone today is getting their questions answered right from AI and not redirected to a static page. Also, when it comes to apps, the tech industry is shifting away from standalone apps to more AI Agents. Musk even stated that in the very near future there will be no Mobile Operating systems, just an AI agent running on your phone. The mindset needs to shift; the playing field rules are being reestablished. I have to ask myself: how do I take NexusDocs.ai which was just a proof of concept to see how powerful AI really is. To an AI agent that would allow people to use it without even needing to be reminded? How do you bring this automation?

This is an issue we all face. You come up with more than just a good idea, but a need. That addresses a serious issue. An app that has true meaning, and in the end, it's so hard to sell it or even get users to try it and leave a comment or a review. I'm in the same situation. I created an app as a proof of concept. Could AI truly build this thing from the ground up and help with marketing it? NexusDocs.ai started as a proof of concept for using AI as a think partner. The first product is TermsGuard — more consumer / small-business focused. It summarizes contracts, terms of service, and privacy policies in plain English, flags privacy and legal risks, and lets you ask follow-up questions and export your responses to a PDF. A real need to give people peace of mind because no one ever reads the Terms and Conditions, NDAs, or most contracts; we just click I accept and move on, not knowing what we just signed. I understand your frustration; I believe everyone here does. In the end, you can offer a free product and still have difficulty getting people to try it or buy into it.

The pivot to stopping at v0.2.0 is a vital constraint. Many of us fall into the trap of 'architectural perfectionism' because it feels productive to polish code, even when the underlying demand hasn't been validated yet. By forcing yourself to stop early, you shift your metric of success from 'code completeness' to 'feedback density'. If you struggle with the urge to keep building, try setting a hard deadline for the first 10 user interviews. If you haven't secured those conversations before the v0.2.0 milestone, you don't write another line of production code. It keeps the focus on the problem space rather than the solution.

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!

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.

But, how would you measure in the first place unless you know something using it and letting you know something can be made better?

How are you currently measuring activation and repeat usage for Recall?

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?

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.

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.