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

The head spa insight — that the real problem was trust, not discovery — is the whole thing, and you found it faster than most people do.

I run a jobs board in the AI space and hit the same shape of problem. "Where are the AI jobs" isn't actually the user's problem, because there are thousands. The problem is that most of what's listed is expired, duplicated, or a recruiter's ghost post. So the product became screening: roughly 37,000 postings run through a filter, a human approves what survives, and filled listings get deleted daily. The listing count was never the product. The deleting is.

That generalises to your certification instinct — for a directory, aggregation is table stakes and verification is the moat. Anyone can scrape the spas. Knowing which ones have genuinely trained practitioners is work, which is exactly why it's defensible.

On building-versus-validating: what partly resolved it for me was making the validation instrument the product's front door. Ours is a six-question quiz someone takes before seeing any results — what kind of work, what level, remote or not. It's a conversation with every visitor at a volume I'd never reach by DM, and the drop-off between questions tells me what people actually care about. Building it felt like building, which scratched the same itch, but every answer is evidence.

So maybe the honest answer to your question is that AI made me faster at turning assumptions into products, and the fix wasn't more discipline — it was building things that generate evidence as a side effect.

Since AI makes execution so fast, I've had to start forcing a simple rule on myself: no new features or UI changes until I can point to a specific user behavior or conversation that called for it. It's easy to confuse activity with progress. Appreciate you writing this down.

I think the interesting part is what happens between the click and the actual use of the product.

Reach can tell you whether the message is getting attention, but activation tells you whether you're reaching the right people. I'd be looking closely at that step rather than optimizing for views alone.

Have you started a third yet?

This is such a common trap. I’ve done the same thing more than once — building first and only talking to people after the thing already existed.

Curious what the main signal was that finally made you realize the problem. Was it the lack of replies, or something more specific people said?

Oo

This hit close to home. Building feels like progress because its measurable and validation isn't. Maybe the real fix is a rule: no code until you've had three real conversations about the problem, not the solution.

Yes — though it’s more reactive than systematic so far. The GEO failure I described taught me to ask: what has to be true one step before the thing I’m optimizing for?

For the content pipeline: what has to be true for content to get cited? It has to be indexed first. I hadn’t asked that before building.

The check I now try to run before scaling: can I point to evidence of the prerequisite working at small scale? One article indexed and appearing in an AI response before I build the pipeline to publish 18. One paying customer before I optimize the checkout flow. It sounds obvious but the tooling makes it easy to skip — you can go from idea to production in a day, and that speed is exactly the trap.

Your framing of “what am I too inexperienced in this space to know I should check” is the harder version of the question. Pre-mortem covers known risks. The unknown unknowns only show up when you talk to someone who’s already failed that way — or fail yourself.

I'm in the middle of this exact cycle right now. Built an AI tool, shipped it, now trying to find users. Your post made me pause and send 5 DMs to potential users before I add the next feature. Small step, but it's the step I was avoiding. Appreciate you sharing this.

"Building feels like progress" is such a spot-on realization. With AI, creating a clean UI or spinning up a full app happens so fast that it gives you an instant dopamine rush before you even know if anyone needs it.
​As someone building a UI tool (NexoreUI), I see this trap every day — it's so tempting to keep polishing components and adding features because code gives immediate, predictable feedback, while talking to users brings friction and uncertainty.
​Asking "Should I build this yet?" instead of "Can I build this?" is definitely the ultimate founder skill right now. Great post!

The behavior you describe makes sense because building gives immediate, legible feedback while validation gives delayed and ambiguous feedback.

One practice that helped us over a longer product cycle was to treat every feature request as a hypothesis with two separate columns: evidence and commitment. A user saying “I need X” is evidence, but it is not yet a commitment to build X. We looked for the repeated job behind the request, then tested the cheapest reversible version first—copy, a manual workflow, a spreadsheet, or a small UI change.

The useful question became: “What would we have to observe to change our mind?” If the answer is only “people say they like the idea,” the test is too weak. Stronger signals are people sharing a real workflow, giving access to ugly examples, returning for a second session, or accepting a manual version before automation exists.

AI makes the prototype cheaper, but it also makes throwing it away emotionally harder because the prototype looks finished. Keeping the first test deliberately small and temporary helps preserve the option to learn instead of defend what was built.

https://www.amazon.com/Mom-Test-customers-business-everyone/dp/1492180742

The "measurement problem" you're naming is the real trap. You can measure building: features shipped, lines of code, velocity. But you can't measure validation through code - only through uncomfortable conversations with humans. So founders rationally optimize for the thing they can measure. AI didn't create this trap, but it weaponized it by compressing the cost of building to near-zero. When a website takes three weeks, that's an expensive validation failure. When it takes three hours, founders feel entitled to ship-first-ask-later because the "sunk cost fallacy" is actually a sunk cost now. The founders who win aren't the ones who ship fastest - they're the ones uncomfortable enough to ask questions before they've fallen in love with their solution.

I think I'm experiencing the same thing. I'm using ai For basically anything: From Building my website to Automate Functions of the website itself. I also validate using Ai, I ask it 'Is there demand For X?' and ai answer, maybe by doing web research, but I never check directly. Building with ai is definetly faster, but the hard part is finding people who actually want to use your product.

"Building feels like progress" hits the spot. Prompting AI gives you that instant dopamine fix—a shiny new UI, a working database—while cold DMing 20 strangers feels like pulling teeth because nobody likes rejection. AI basically made building so effortless that it became our favorite way to procrastinate on actual validation. Super honest reflection, thanks for sharing this.

This is one of those lessons that sounds obvious in hindsight: building faster doesn't matter if you're building the wrong thing. Talking to users early can save weeks of development.”

i think your API keys are leaked!update your front end code

This really resonates. AI has made building so easy that it can feel like validation when it’s really just execution.

I like one simple question for this: What uncertainty am I reducing right now?

Sometimes 5 user conversations move the business forward more than 5 new features. Maybe the new founder skill isn’t shipping faster, but knowing what needs to be learned before shipping.

This resonates hard. The painful irony we see running forgex.systems is that founders who build too early often spend their tech budget on the wrong thing, then come to us to "fix" what could have been avoided.

The founders who move fastest through us are the ones who've had exactly 10-20 conversations that revealed a specific, recurring pain before they touch a spec. Having a waitlist of 50+ and resolve their pain points.

Your reframe from "can I build this?" to "should I build this yet?" is the exact question I wish more founders brought to us on day one.

AI made me 10x faster at turning assumptions into products. That turned out to be the problem.

Two months ago I built an automated content pipeline — an agent that researched, wrote, and published GEO-optimized articles daily. Two weeks, 18 articles. Every step ran cleanly. Revenue: $0. Citations: zero. Indexed pages: zero.

The diagnosis took another week: Google hadn't crawled a single post. I'd been optimizing the production step — the one AI made effortless — without ever verifying the prerequisite. The chain is: indexed → AI crawlers discover → AI cites. I hadn't cleared the first gate.

Your phrase "I built first and figured I'd tell people later" maps exactly. I built first and figured I'd verify distribution later. The automation made it easy to rationalize skipping that check — "I'll just launch and see." At manual pace, 18 articles takes months and you notice sooner when nothing's happening. At agent pace, two weeks passes before you realize the clock never started.

So: AI didn't make me better at testing ideas. It made the consequence of not testing arrive faster, and in larger batches.

The repeated mistake suggests the real constraint is no longer building speed; it is creating a forcing function for evidence. I’d make the rule behavioral rather than aspirational: before adding the next feature, collect five examples of the painful moment in the user’s own words and one costly action they already take to solve it. For the spa directory, certification became meaningful only when owners raised it unprompted—that is much stronger than a trend or a signup. A small build can still be useful if it is designed as a question: a profile mockup, concierge listing, or paid verification offer that can clearly fail. What evidence would make you stop either project now, rather than simply reposition it again?

Spa owners bringing up certification unprompted is the signal, and you only got it by talking. That argument is usually already running in public, customers asking how to tell whether a place is genuinely trained, long before anyone builds a directory. Viewfy's thread scout reads that phrasing before a site exists. Both directories may still work out, the order just costs you a rebuild each time.

The practical test I use now is: can I describe the painful moment before describing the product? If I can only pitch the thing I built, I am probably still validating my imagination, not the customer problem.

As someone who spends a lot of time building web applications and digital utility tools, this hits incredibly close to home! AI has absolutely made me faster at turning assumptions into products, and it's a constant battle to pause and have those uncomfortable conversations first. Your realization about the scarce skill shifting from 'Can I build this?' to 'Should I build this yet?' is a perfect summary of the current landscape. Thank you for the honest reflection!

The part about building feeling like progress is the real trap. I’ve started separating validation into four questions before touching the product: Is the problem frequent enough, are people already spending money or effort on it, can I name a reachable first customer segment, and is there a believable path to the first 10 customers? If one of those is still vague, the next step should generate evidence rather than features. A landing page can help, but I’d treat signups as weak evidence unless people also reply, book a call, pre-order, or take another costly action. What did the spa owners say that changed your direction most?

There’s a version of this that applies past the building stage too — a lot of founders (and honestly a lot of buyers doing diligence) skip straight to the numbers before really talking to the people behind them. What clicked for you once you started those conversations — was it a specific pattern in what people said, or more just realizing what you’d been assuming?

The trap of modern development is exactly how you described it: AI has lowered the barrier to shipping so much that the 'cost of being wrong' now feels like zero. When you can spin up a directory or a landing page in an afternoon, you lose the friction that usually forces you to validate whether the pain point is real before you commit to the code. You're not just building; you're essentially gambling that the problem you imagined has a market-ready audience behind it. Recognizing that 'ease of building' is a different metric than 'value creation' is a huge shift in maturity for a founder. Next time you have an idea, try a landing page with a waitlist that forces you to articulate the specific value proposition for a specific customer type. If you can't get three people to sign up based on a description, you've saved yourself the work of building the actual directory, which is the best kind of 'failure' you can have.

Funny timing, I left a comment on that same job hunting thread, so your quote comes full circle.

Honest answer to your closing question, AI made me faster at both, and the direction it points depends entirely on what I aim it at. I haven't done the interview users step either. What saved me was an accident of format, my product is a personal finance site whose free half is a pile of small single purpose calculators, and each one answers a question people type into Google. So every page doubles as a validation instrument whether I want it to or not. Search demand is a user interview that never cancels on you. It has worse follow-up questions but a much bigger sample size.

The paid half was still a bet built on assumptions, same as you. The difference is the bet sits on top of pages where demand was beginning to become measurable, so the worst case was the paid thing flops on a free site people still use rather than nobody wanted any of it to begin with.

Where AI actually changed my behavior was this week, and it's the opposite of the trap you're describing. I pulled all of my Search Console data and had it paired against my pages, which queries earn impressions on a page that answers a different question. That analysis picked my next build for me. There was a cluster of a hundred plus impressions for a calculator I don't have, landing on a neighboring one I do. So the next thing I ship was chosen by evidence, and building it is the validation step.

Maybe that's the reframe, the problem was never that building is cheap. It's that building used to be so expensive we needed certainty first. Now it's cheap enough that a page can BE the question you ask the market. But only if the thing you build is small enough to be a question.

Your "should I build this yet" framing is good. I've asked myself what's the smallest thing I can build that generates evidence as economically as possible instead of consuming my certainty.

The "building feels like progress" diagnosis is sharp. AI collapsed the cost of a polished site so hard that the dopamine hit now arrives before any customer signal does. What helped me break that loop is treating the first conversations as the product: five real replies from spa owners or founders beat another week of directory features. Ship a landing page only if it is a question you are asking people, not a product you are defending.

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.