I built two websites before talking to users. I think I see the problem now.

I did the reverse of your experiment after reading this: opened both sites cold, as a stranger, to see whether the pages have caught up with what the conversations taught you.

HeadSpaDirectory mostly has. "Find a Real Japanese Head Spa" plus "a trust filter, not a generic ranking" is the certification insight, right in the hero. One gap: the Signal Score's visible checks (dedicated page, online booking, price listed, treatment steps) verify a spa's website hygiene, not the thing you said actually matters - training and practitioner background. The page promises the new value, then proves it with the old signals.

AIStartupOfOne still sells the earlier hypothesis: the hero promises founder stories and profiles, while your post says the value moved to the decisions behind them - what NOT to build, what evidence was enough to keep going. That page hasn't caught up with you yet.

Maybe that's the practical version of "validate first" for people who are going to build anyway: the landing page is a statement of your current hypothesis. Every time a conversation moves the hypothesis and the page stays put, visitors are testing yesterday's version of your idea.

Building is just a comfortable way to procrastinate on doing actual customer research

Validating before coding is a hard lesson almost every founder learns the hard way. If you ever decide to offload those initial builds, don't let the code go to waste—there's usually someone looking for starter projects. I built Digimarket with an AI valuation tool for this exact reason.

Validating before coding is a hard lesson almost every founder learns the hard way. If you ever decide to offload those initial builds, don't let the code go to waste—there's usually someone looking for starter projects. I built Digimarket with an AI valuation tool for this exact reason.

The shift from "can I build this" to "should I build this yet" is the whole post in one line for me. AI didnt create this problem, it just removed the excuse of not having time to build first and ask questions later.

The "building feels like progress" framing is exactly right and I don't think it gets talked about enough. Building gives you the dopamine of forward motion without the discomfort of being told your assumption is wrong. Talking to users gives you the opposite: slow, uncertain, occasionally demoralizing feedback that sometimes saves you six months.

I went through a version of this for a solid year. Built features, polished things, kept asking "what's missing?" instead of "who actually wants this?" The features were fine. That wasn't the problem. The problem was I was answering engineering questions before I'd answered customer questions.

The thing that shifted it: I stopped asking "do you like this?" in conversations and started asking "when did you last have this exact problem?" That question either surfaces a real recent pain or reveals someone being politely interested in an idea. The gap between those two responses is enormous.

To answer your question directly: AI made me faster at turning assumptions into products. I became better at testing ideas the hard way — by running out of things to build and being forced to talk to people.

Building feels like progress” is such a good way to frame it. AI has made execution faster, but it hasn’t made validation any easier. The real challenge now may be knowing what evidence is enough before building.

One thing I might test in the second project is to treat the profile as the interview invitation, not the product. Pick 10 founders, show them a deliberately incomplete profile, then ask what decision they wish they had documented at the time. If the same missing decision keeps coming back, you have a clearer product direction than another round of adding profiles. It also gives each week of validation a visible output.

Recently started my first project. I have done things in the most outlandish order. But, one thing I have noticed is when I am using AI to code, I do spend a lot of time doing what feels like busy work. Nothing is being solved, but I am running different lines of code or prompts to try to push fusher. It has made it easier to test ideas, but it takes away part of the due diligence aspect. We have the ability to throw out different websites/ideas that don't take that much to create. Vetting these ideas is not as necessary

The “idea → build → launch → learn” loop can seem productive because something is tangible at each step. The issue is that all of those outputs do not necessarily decrease uncertainty.

I think it's helpful to differentiate building progress from learning progress. A second site can be a lot of trouble and little to no new learning about whether the problem matters.

The change of mindset from considering the question: Should I build this? to: What do I need to learn before building this? is a subtle one but can make all the difference. The number of weeks that can be wasted on one or two meetings is quite surprising.

The question regarding the rationale behind the founders building is particularly significant. Sometimes it's not the problem of execution in itself—it's the problem of getting used to the idea that it should change.

AI made building and validating both faster, so the sequence you pick matters more than ever. The founders I back who win use AI for the uncomfortable half first, drafting outreach, summarizing interview notes, pressure testing assumptions, before a single page exists. Building was never the scarce skill, tolerating the discomfort of being questioned is.

I recognize this pattern in myself too. Building is the comfortable part because there is always a clear next step. You add a feature, fix a bug, improve the UI, and at the end of the day you can see what you accomplished.

Talking to people is much less predictable. You can spend hours reaching out and get nothing back, or get feedback that makes you question something you already spent weeks building.

I think AI makes that difference even bigger. It gives us the ability to build faster, but it doesn't make people care faster.

I'm trying to remind myself that another completed feature isn't always more progress than one useful conversation. That's much easier to understand than to actually practice.

Talking to users early is the fix, but the hard part is what to ask. I ran the same loop for 3 months on my own product — the questions that changed my roadmap weren't "would you use this?" (everyone says yes) but "what did you do the last time this problem came up?". Past behavior beat stated opinions every time. Your founder interviews are already pointing there: the decisions are the real data.

The trap isn't that you didn't know you should validate. It's that "validation" has no measurement system. Every other phase has one: building has a finished feature (it works), shipping has a date (launch happened), scaling has metrics. But validation? "Talk to users" doesn't tell you when you're allowed to stop. So your brain keeps asking for one more conversation. You showed this perfectly: both projects got sharper through conversations, but there was never a point where the conversations said "you have permission to build." If I had to guess at what changes, it's not your discipline. It's defining "validation is complete" with the same specificity you'd use for "the feature works"—a number (10 conversations) and a decision (does the pattern hold) before you start, not after. Right now you're measuring effort (we talked to people). What if you measured readiness instead (we found the evidence we needed)?

The bit I'd add: "validate first" loses to "build first" not because people forget the advice, but because validation has no definition of done.

Building has a visible finish line. The page renders, the feature works, you can point at it. Validation doesn't. There is always one more conversation you could have, and no moment where anyone tells you you're allowed to stop. Given a task with a finish line and a task without one, the brain picks the first every time and calls it progress. That isn't a discipline failure, it's a missing shape.

So the thing that actually worked for me wasn't more willpower, it was giving validation the same shape building has: a number and a date, written down before starting, with the decision pre-committed in both directions.

Mine, in the open, since you asked for receipts. Landing page for a QA service, fixed price per sprint, and a kill condition I wrote before I built anything: 3 paying customers or 25 signups within 14 days, or I change the offer exactly once and then park it. Day two, currently zero of both. That is genuinely uncomfortable to type, which is rather the point. Writing the number was easy. What it actually costs is that in twelve days I won't be able to talk myself into "it just needs a bit more polish".

One thing worth saying about your own two though: both projects got sharper the moment you talked to people, so the conversations were working fine. What was missing wasn't the talking, it was the point at which the talking was allowed to end and a decision got made. And a directory of one-person AI companies where you interview founders about how they decided what not to build is a fairly good description of validating your own question in public. I don't think that's the same mistake a third time.

The “building feels like progress” point is probably the most interesting part here. AI removes so much friction from execution that it becomes very easy to mistake activity for evidence.

I’m curious whether your conversations changed the direction of either project enough that you’d now build something substantially different from the original version.

I think the “building feels like progress” part is the real trap. AI has made the cost of turning an assumption into something working so low that it can actually make validation feel slower than building.

The harder question now might not be “can I build this?” but “what evidence do I need before I earn the right to build it?”

I’m curious whether you think the answer is simply stronger validation habits, or whether AI could eventually help founders stay in the evidence-gathering phase without immediately jumping into implementation.