I made a mistake every first-time founder makes — I built first, validated later. Here's what I'd do differently.

the 'watch the face not the words' thing is so true. ran a hosting biz for 18yrs and my most expensive assumption was that ppl who hit usage limits would just upgrade if I emailed them. they didnt — they churned silently. once I started calling them before they hit the wall instead of after, upgrade conversion got way better. ur 'when did you last feel this' reframe is exactly right imo. how do u plan to keep that habit once u cant physically walk into every jeweller's shop?

This is gold. Thanks for sharing, Suhail.
I can't call myself a founder, but I've failed enough to resonate with you from my side projects.

What you shared as "Simple. Obvious" is basically the same thing an entrepreneur coach once shared with me in a USD697 per month program. Somehow paying that money still didn't push me enough to just walk out my door and talk to real people.

So I feel sometimes the real question might be identifying what that mental block is. At the time of writing this, I have no idea.

This is the part I keep coming back to:

“Will a painful enough user take an annoying workaround before the polished thing exists?”

That’s a much better validation bar than “people said it sounds useful.”
I’m trying to apply this by spending less time explaining the product and more time finding people already describing the pain in their own words.

For me, the useful signal is not:
“Cool idea.”

It’s:
“I have this problem.”
“I tried X.”
“It didn’t work.”
“I’d talk about it because it’s still painful.”

Curious: what was the first signal that made you think the pain was real, not just intellectually interesting?

"Such an honest and valuable post. 'Free users lie, paying users don't' is a lesson every first-time founder needs to hear. It’s so tempting to hide behind code instead of sitting down with real users and asking the hard questions. Appreciate you sharing this validation framework—saving this for my own B2B project discovery!"

Point 2 is the one that takes the longest to believe. Getting someone to pay $1 tells you more than 100 'I'd definitely use this' responses.

Doing this right now with BillWatch - a federal bill tracker for small business owners. Pre-orders at $9/month before any backend is built. The question that keeps filtering signal from noise: 'When did you last learn about a federal regulation after it was already in effect?' People who have a specific story are the real customers. People who say 'yeah that happens sometimes' are not.

Six days into a 14-day sprint. billwatch-landing.vercel.app if you want to see the approach.

Your point about watching faces vs. listening to words is exactly why I'm adding phone calls alongside the landing page.

I think it is very common that we build things and get caught up in our own bias that the product will be successful and will have customers right at launch, but it is extremely rare that things go like that. Same thing happened to me

Saw the same thing from the other angle this month — I shipped 319 small things over 6 weeks before checking whether anyone wanted any of them. 0 installs in the top 200 of my marketplace, $0 revenue. The signal I should have read on Day 5 instead of Day 42: when distribution channels aren't even registered yet, the bottleneck is never going to be production. The volume is the problem, not the solution. Hard freeze on building, distribution-only for the next 7 days — if it doesn't move a single install I shut it down. Sometimes the answer is fewer things, not more.

My most expensive assumption was that online sellers would find PixPipe by themselves just because it solved a real problem. I built the whole thing first, compression, EXIF stripping, AI upscaling, and then launched to crickets. What actually worked was writing guides targeting exact searches like 'how to resize photos for Poshmark listing.' Suddenly I had a page on Google page 1 and real users showing up. The lesson: for tools serving non-tech users (sellers, not developers), distribution through search intent beats any launch strategy. Caught it about a month in, but wish I'd validated the SEO angle on day 1.

Thats kinda nice

This resonates hard. I went through the exact same arc — built the whole thing, then realized nobody had actually asked for it.

The thing that changed my approach was replacing "would you use this?" with a simple 3-criteria scoring system before I write any code: (1) standalone value — does this help someone without network effects?, (2) build speed — can I ship in a weekend?, (3) gate risk — are there app stores, legal, compliance blocking launch?

If an idea scores below 5/10 on that scale, I don't build it. If it's 7+, I ship. The scoring itself takes 10 minutes. The ROI is that I don't waste 3 months on an idea that was never going to clear the gates.

The "watch the face, not the words" insight is gold — especially in cultures where people say yes to be polite. I found the corollary for digital products: watch where people drop off, not what they say in surveys.

The "would you use this?" vs "when did you last feel this problem?" reframing is perfect. I wasted weeks building features nobody asked for because I confused
"that sounds cool" with "I need that."

What I'd add: even after validation, the product you build will be used differently than you expect. We built 14 AI tools for YouTube creators and the most popular one turned out to be one we almost didn't ship — a simple SEO score checker. We thought the AI script generator would be the star. Turns out creators don't want AI to write for them, they want AI to tell them what's wrong with what they already wrote.

The ₹199 test is brilliant. We did something similar — a generous free tier that gives real value, not a crippled trial. The logic is the same: actual behavior (upgrading, paying, returning daily) tells you more than any survey. Our conversion insight was that users who generated 5+ pieces of content in their first week had 3x higher upgrade rates — that was the real validation signal, not signups.

the part about offline B2B validation in India is something most generic "talk to customers" advice completely misses. the technique changes entirely depending on who your customer is.

for offline B2B buyers — jewelers, retailers, trade businesses — the actual validation signal isn't "yes I'd pay for that." it's whether they'll do something uncomfortable to get it: agree to a working session, introduce you to someone else in the supply chain, share their current spreadsheet or manual process with you.

the asymmetry you're describing usually comes from validating intent instead of validating willingness to change. people who've done something manually for 20 years will enthusiastically say they want to digitize it. that enthusiasm rarely survives the friction of actually switching.

what finally worked for you to close the gap between interest and becoming an actual paying customer?

Yeah, it's one of a big challenge. in early days Actually what is real work? When we realize An assumption build . We love everything. Because the town assumptions when we will go This problem is really valid. No one wanted When we realize that one. One of a big challenge to come out of that. There are really two types of challenges. In early days. One is We especially love that assumption. One must should be avoided. Loving overconfidence on Well actually come to assumptions actually come to talk to with real customers. No one wanted that product. It's not solve a real problem. See When we ask the questions like As for our product . When we go for marketing one of a distribution? On that time when we go. and ask The first question is Old use This is completely waste of asking. Instead of that one we need to ask And will you pay for this? It will solve your real problem. That will decides. Validation.

It's interesting that you mention validating after building, as this is a common pitfall many founders fall into, and it's great that you're sharing your lessons learned to help others avoid this mistake. I'd love to hear more about what you did differently after realizing your approach wasn't working, and how you went about validating your product with potential customers. Did you pivot your product or messaging in any significant way as a result of the validation process?

Building first and validating later is the default. Don't beat yourself up. Almost every first-time founder does it. The important thing is that you recognized it and are course-correcting.

The shift that changes everything is talking to potential users before writing a single line of code. Not surveys. Not landing pages. Real conversations where you listen more than you talk. Most founders skip this because it's uncomfortable. But a dozen honest conversations will teach you more than a year of building in isolation.

Your second product will be faster, leaner, and closer to what people actually need because you've already paid the tuition on the first one. That's not failure. That's the curriculum.

The "watch the face, not the words" advice is underrated — especially in contexts where saying no feels socially awkward. The Indian small business owner example is a perfect illustration, but honestly this shows up everywhere: B2B demos, user research calls, even talking to friends about your idea. People are wired to be encouraging.

The question shift you described is the real unlock. Instead of "would you use this?" asking "when did you last feel this problem?" forces specificity that politeness can't fake. If they can't recall a concrete moment, you're validating a vague frustration, not a real pain point. I'd add one more: "what did you do about it last time?" — if the answer is "nothing," that's a signal the pain isn't actually motivating enough to pay for a solution. Your point about building the riskiest assumption first is the hardest to internalize because it usually means showing something ugly you're not proud of, but it's the only test that actually matters.

The “watch the face, not the words” part honestly stood out to me most.

I think a lot of founders accidentally validate politeness instead of intent.
Especially in early conversations, people often reward effort emotionally before they’ve actually decided the problem matters enough to change behavior or pay.

That’s probably why so many founders get stuck in the “people like it” but not “people need it” stage.

Also really liked your point about testing the riskiest assumption first.

I’m starting to think most startup mistakes aren’t from lack of effort, they come from spending months optimizing around the wrong assumption.

curious where JewelViz is now after going through this. you described the mistake clearly but the interesting part is what changed after. did you go back and do the 20 jeweller visits or did you pivot the product based on what you found out late? and when you showed the AI generated images to jewellers, what did their faces actually do? that reaction seems like the most important data point you have

My most expensive assumption was that visual appeal alone would drive people to try it.

I built something that generates AI trading cards. The output looks genuinely impressive with detailed artwork and the whole thing. I assumed that if it looked amazing, people would naturally want to create one.

One week after launching I realised nobody was asking "how do I make one of these." They were asking "what is this for." The product answered a question nobody was walking around with.

I caught it fast but only because I was obsessively watching every session and comment. The silence was loud enough.

Still figuring out how to close that gap between "wow that looks cool" and "I need to make one right now." Turns out those are very different reactions.

Validate the clarity before validating the product. That is going on my wall. The building as avoidance pattern is real. I caught myself doing it again last week. Started coding a new feature instead of writing a one sentence description and showing it to three people. The three people test is faster than any code I could write.

The "I validated after building" pain is real — but there's a validation layer most founders skip even when they do it right: AI search visibility.

Before launch, founders test with potential users. After launch, they check Google Analytics. Almost no one checks what ChatGPT, Claude, or Perplexity says about their product before a buyer asks.

We found out the hard way: AI was recommending two competitors in our category that were less active than us. Our key differentiators weren't in any LLM's response. The framing that resonated with human users? Completely absent from AI outputs.

Google validation you can fix post-launch (Search Console, backlinks, schema). AI training data is slower to update — the window to shape what LLMs say about you is narrower than people think.

Validate with humans. But also check the AI layer before you ship.

Your "free users lie, paying users don't" line is the one that should be tattooed on every first-time founder's desk.

My most expensive assumption: I thought trades and field service owners wanted powerful and feature-rich. They wanted fast and simple. Two very different products.

I built a full scheduling engine with complex logic before I realized most of my target users just wanted to stop texting their crew every morning to ask where they were. That's it. The sophisticated stuff came later — but I almost buried the simple thing they actually needed under layers of complexity they didn't ask for.

Your point about watching the face, not the words — that's the whole game when you're selling to non-tech customers. A plumber or a contractor will tell you your product is great while mentally going back to their whiteboard and paper routes. You only know it landed when they pull out their phone and start using it in front of you.

Caught it about 6 weeks in. Cost me a month of rebuilding. Could've been worse.

Good luck with JewelViz — the fact that you're doing in-person validation now puts you ahead of 90% of founders at your stage.

It's refreshing to see a founder openly sharing their mistakes, and I think many can relate to building first and validating later. I'd love to hear more about what specific steps you took to validate your product after the initial launch, and how that process helped you refine your approach. What changes did you make to your product or marketing strategy as a result of the feedback you received from those early interactions?

Suhail is so right,
If you're building something and want to know how your market actually argues about it, we'd love to help.
We're building Assembly, a synthetic society simulator. You give us a product, a price, and a target audience. We spawn hundreds of AI agents grounded in peer-reviewed behavioural science and real-world demographic data, run them through multiple rounds of structured debate, and show you exactly who accepts your product, who resists it, and what argument shifts minds.
Not a survey. Not AI guessing. A synthetic society of agents that challenge each other, shift positions, and form emergent consensus, the same way real markets do.
If you're pre-launch, deciding on positioning, or about to commit to something before you have a real signal, drop a comment. The first simulation is free.

"Watch the face. Not the words." — this is literally the first thing taught in user research training, and most founders never learn it because they never sit in the room.

The validation problem you're describing is actually a UX research problem in disguise. The reason "would you use this?" is useless is the same reason usability tests ask people to think out loud while doing a task - not rate it afterwards. Behaviour is honest.
Opinions are polite.
Your week-by-week framework is essentially a lean UX sprint. Most people who teach this charge thousands for it.

My most expensive assumption as a designer: that users would "figure it out" if the product was good enough. They won't. They'll leave and never tell you why.

This is such a valuable lesson, especially the part about watching behaviour instead of listening to polite feedback.

We’re learning something similar while building our own AI product. People may say “privacy is important” or “this sounds useful,” but the real question is: will they actually trust it with real work, sensitive data, and pay for it?

I think the “riskiest assumption first” point is huge. For us, the riskiest assumption is not whether AI is useful — everyone knows it is. It’s whether people care enough about privacy, control, and predictable usage to switch from tools they already know.

Really appreciate how honest this post is.

validation is teh hardest part because it forces you to face rejection before you even have a product. it's much easier to just write code and pretend you are making progress. but building a landing page or just talking to five potential users saves months of wasted effort.

I think some technical B2B products are tricky because the problem already exists very clearly for users internally.
The hard part is often not validation of the pain itself, but reaching the few people who are close enough to the operational problem to care deeply about it. This is the problem I am actually facing now.

The landing page test is underrated. I did the same thing, built for 3 weeks before showing anyone. When I finally put it in front of users, half the features I spent time on were irrelevant. The one thing people actually wanted was something I almost cut because it seemed too simple. Now I try to validate with the minimum possible artifact. A landing page, a mockup, even a written description of what the tool does. If people do not care about the description, they will not care about the product.

Same mistake. Built Creator Wrapped before talking to a single creator.

It's a Spotify Wrapped for newsletter creators. Top post, fastest-growing week, superfan city - all in a shareable card in one click. Substack, Beehiiv, ConvertKit. Free.

My assumption: newsletter creators want to show their audience a year-in-review card, the same way Spotify users share their Wrapped every December.

What I didn't test: whether May is the wrong month for this, or whether platform analytics already fill the gap.

72 hours post-launch. Zero signups. Gate on May 20.

Still running it. If you have a newsletter and want to see your 2026 in numbers: creator-wrapped-hazel.vercel.app

Same trap here. I've spent 6 weeks on my sprint planner UI before talking to a single PM. First call wiped half the feature set. Now I do 5 conversations before writing a line.

Man, this resonates so hard. We are building in the blue-collar space right now with FixRAgent (AI triage for property maintenance/DIY), and our validation journey was a wild ride.

Our biggest advantage was that we didn't have to guess the pain point—my husband and I built it to solve the bleeding we were experiencing firsthand in our own real estate portfolio. We knew the $150 "blind dispatch" fee was a massive problem. But our most expensive assumption? Assuming our users cared about the tech. We spent months using 'founder words' like diagnostic pipelines and multimodal triage. It wasn't until I texted my best friend—who was frustrated trying to build a wall sconce—and she said, 'Wait, so I can just take a picture of the box and it tells me what to do?' that it clicked.

We were selling 'AI Triage' when our users just wanted an 'Anti-Rabbit Hole' button for YouTube and Home Depot. Lesson learned: Build the tech like an engineer, but sell it using the exact words your customer says when they are staring at a broken appliance in frustration.

This one hits. The "build first" trap usually isn't about being lazy or skipping research — it's that building feels like progress and validation feels like rejection waiting to happen. I came from 10 years of phone sales before going independent, and the thing that finally clicked was treating validation exactly like a sales pitch: if I can't get a stranger to react to the problem in one message, the product won't fix that. Cheaper to hear "no" from 50 outreach messages than from a finished product. Did you find a validation format that actually felt natural, or was it forced at first? Mine felt deeply uncomfortable for the first two weeks.

The riskiest assumption first point is the key one, but I would frame it differently: the question is not which assumption is risky, it is which one takes the longest to falsify. Some assumptions you can test in a WhatsApp message. Others need months of real usage data.

The face-watching observation is specific to B2B in markets where directness is culturally costly. In that context, willingness to schedule a demo (not just say yes to one) is a better signal than words. Getting someone to put time in their calendar before your product exists sorts real pain from polite interest faster than any paid pilot.

Good approach, may this serve as a lesson for all who dare to launch a product, CONGRATULATIONS!

Really good breakdown. I’m building a tech product and this hit me hard — especially the part about testing the riskiest assumption first. Easy to get lost polishing features when the real question is “will anyone actually trust/use this?” Thanks for sharing, this saves me from repeating the same mistake.

The question switch from "would you use this?" to "when did you last feel this problem?" is such a small reframe but it completely changes the quality of the answer. One stays hypothetical, the other pulls from actual memory — and memory is where real pain lives. My most expensive assumption was that users would engage with a feature if I just made it visible enough. Turns out discoverability is irrelevant if the underlying problem isn't urgent for them. Your point about free vs. paying users is also underrated: I spent months optimizing for "active users" who had never committed a single dollar, and it told me almost nothing useful.

I did
the same thing you did. Built everything. Polished the site. Launched.
Then sat there refreshing the dashboard waiting for signups that never
came. Zero. I'd spent months on a tool to reduce uncertainty and never
once pointed it at my own biggest uncertainty: does anyone actually
want this?

Took me weeks to say that out loud. So reading you put it this plainly,
with your name on it, genuinely meant something.

The line that got me was "when did you last feel this problem?". A
polite "yeah, I'd use that" kept me comfortable for months. A real
memory would've saved me those months.

You're already doing the hardest part — looking straight at it instead
of away. Rooting for you and JewelViz. Now go talk to those 20 jewelers.

Totally Agree, but what about product that is not for physical store for instance any software related tool? Secondly where do I find my potential clients?

The 'watch the face, not the words' observation is the most underrated validation tip I see in these threads. Body language forms before the rationalized answer does.

Two others that changed how we run validation:

Price anchoring in the conversation. Instead of 'would you pay for this', say 'most tools like this run $50-200/mo -- does that feel right for what you described?' The number is a Rorschach test. If they flinch fast, you have your answer before they find the polite version.

Binary gates before you start. Set a pass/fail threshold before the sprint, not after. Not 'let's see how it goes'. Specific: 3 paying customers in 14 days or we pivot. Without the gate upfront, validation never actually ends -- it just morphs into premature building again.

We ran enough of these cycles that we packaged the whole workflow into a toolkit (validate.3vo.ai) for the sprints. Codifies the process you're describing into a repeatable sequence.

"Free users lie. Paying users don't." — this is the line I needed to read today.

I'm a few days from opening a free beta, and your post just made me uncomfortable in a useful way. A free beta is great for catching whether the product breaks. It tells me almost nothing about whether anyone will pay. I think I was quietly hoping "people love it for free" would translate to "people will pay" — and that's exactly the assumption you're warning against.

My most expensive assumption so far: that the problem I personally feel is felt the same way by others. I built around my own frustration without sitting down with enough people who have it. Still catching that one.

Watch the face, not the words — saving that. Good luck with JewelViz.

The build-first mistake is almost universal. The pattern I've seen: people do 'user research' but phrase questions as 'would you use this?' - yes-bait - instead of 'walk me through how you currently solve this' - behavioral signal.

The thing that changed our process: setting a hard go/no-go gate before writing any code. Specific number of interviews at a specific WTP threshold. If you don't hit it by day 14, you kill the idea and move on.

We formalized this into a 14-day framework at 3vo.ai - a validation prompt pack that walks through customer interviews, landing page tests, and unit economics in sequence. It's the thing we build every product against now. The discipline of the gate matters more than the framework itself.

Really grounded, bhai!!! I like those practical approaches and honest experience. My day job is pipeline forensics, predicting the remaining life of vintage water and sewer pipes from incomplete records. After 40 years across customer sales, engineering, and forensics, I've learned that Judgement is the order of the day: enough exposure to failure mechanisms and modes, enough material physics, enough scars to know which dot connects to which. In the after-hours I've been building with AI for the past year. AI helps, but it leans on historic records and standards, and interpretations of the "Why" regularly is on a runaway train. Keep the solution simple, find out Why is it a problem.

The "watch the face, not the words" line stuck with me — that's the part most validation posts skip. My most expensive assumption with my small iOS memo app (a Captio replacement I'm building solo): I thought early users wanted iCloud sync. I built a sync prototype, asked them about it, and they all said "nice" — same "haan bhai achha hai" energy. Their actual behavior showed they only opened the app for one-tap email-to-self and never checked across devices. I caught it after maybe 25 wasted hours. The fix was deleting the feature. Watching face over words also applies to silence: users who "didn't have time to test" were the truest no I got. What's the smallest signal you trust now over a verbal yes?

The "watch the face, not the words" line is the part I wish someone had told me three products ago. Polite agreement is the most expensive false signal in early validation.

My most expensive wrong assumption: that the people who said "yeah I'd use this" in DMs would actually open the product after install. I built a Chrome extension assuming install = intent. Real intent only showed up when I asked them to do one specific thing within 24 hours of installing — that filter dropped my "validated" list by about 70% and saved me from building three features nobody wanted.

Your Week 1 / Week 2 / Week 3 / Week 4 plan is the version of validation I'd hand to my past self. The "ask for payment before building" step is the one almost everyone skips, including me.

I partially agree with this.

Validation is important, but I also think some products are difficult to validate properly before a certain level of execution exists.

Especially when the value comes from:
UX,
quality,
trust,
rendering,
or the overall experience.

Sometimes users can’t really understand the product from a simple landing page or waitlist.

I’m currently building an AI SaaS myself, and I realized that some of the most important feedback only appeared once people could actually interact with a polished version of the product.

That said, the core point is still true:
building in isolation for too long is risky.

The challenge is probably finding the balance between:
validating early
without shipping something too incomplete to demonstrate the real value.

"Watch the face, not the words" is the most honest thing I've read about B2SMB validation.

The stated/revealed preference gap is brutal in this market. Small business owners are polite by default -- they'll nod at anything you show them. The only reliable signal is commitment of something scarce: their time to a second meeting, their staff to run a test, their money for a pilot.

The "build the riskiest assumption first" point hits hardest. Most founders build the feature because it's satisfying to build, and test the demand assumption last because it's terrifying. But the demand assumption is the one that kills you.

The practical reframe I've found useful: before writing any code, ask yourself what would have to be true about your customer's behavior for this to work, and then go find the minimum evidence that behavior exists. Not a survey. Not a landing page click. Actual behavior -- someone doing the manual version of what your product does, or paying you to do it by hand.

For JewelViz specifically: did you ever try charging jewellers for a manually-created digital mockup service first, before automating it? Curious whether the human version validated faster than the AI version.

The 'riskiest assumption first' principle has a new category most founders are skipping right now: whether clients actually want AI-generated outputs at the price they're already paying.

Most freelancers and small agencies are validating workflow, pricing, features - but almost none are directly testing the assumption that matters most in 2025-2026: does my client know AI was involved? And would it change how they value the work?

The face test applies here too. Pitch a client knowing you used AI for 80% of the deliverable. Watch the face. Not the words.

Some will say 'great, efficiency is good.' Their face says something different. And that's when you realize you validated everything except your actual riskiest assumption.

The hardest thing to internalize is that validation isn't a phase, it's a continuous failure mode. Six experiments deep and I still catch myself building three days into a hypothesis before checking whether anyone was waiting for that specific shape of solution. Curious which signal you trust most now - direct user interviews, behavioral logs, paid-to-test, or something else.

Felt this hard. I did the same with Toolivoo — built a full suite of free browser tools before asking anyone if they wanted them. The thing that saved me was the tools being genuinely useful to myself first. Scratching your own itch at least gives you one real user while you validate.

Totally agree on this. Shipping early and getting real feedback beats spending months perfecting something nobody asked for.

This resonates — I built a passport photo tool for Indian NRIs and made the exact same mistake of building before validating. The validation signal that finally told me I had something real wasn't surveys or polls. It was watching people on Reddit spend hours trying to manually resize photos to 630×810 pixels in Paint. They were already in pain. I just had to show up with the solution. Your "watch the face, not the words" advice is spot on for Indian markets.

Totally agree — I learned this the hard way when building my first product. Execution always reveals what theory misses.

The strongest bit here is asking for payment before building, but I’d make it tied to one specific outcome: “would this help you sell one more item this week?” If they can’t name the money event, the mockup feedback will still drift into polite encouragement.

The same pattern shows up on the client side for freelancers. Most client intake processes are build-first, validate-later in disguise - the freelancer starts work based on a brief that captures what the client said they want, not what they actually need.

The worst version: the deliverable is 80% done and the client says 'actually I was thinking something different.' The fix isn't more discovery calls; it's a structured intake brief that forces clarification on the three things clients least articulate upfront: success criteria, constraints, and decision-maker alignment.

The parallels to your build-first mistake are striking: both involve mistaking stated requirements for validated requirements. The only difference is the cost of revision - a pivot at week 4 is painful, a pivot at revision request 3 destroys the relationship.

Spent 20 mins thinking about your post because it's the exact problem I'm solving.

You're right that most validation advice is BS for anyone selling to offline businesses. You can't A/B test when your customer is a jeweller in Saharanpur. You have to actually sit there and figure it out.

I'm building a validation tool because your 4-week framework works but it's not repeatable — everyone has to learn it the hard way. Trying to systematize what you learned.

Real question though: if you were doing this again tomorrow, what's the one day-to-day thing in those first 4 weeks that would've saved you the most time?

It's interesting that you mention validating later, as I've seen many founders fall into the same trap of building a product without a clear understanding of their target market's needs. Can you elaborate on what specific steps you would take to validate your product idea before building, and how you would gauge interest from potential customers? This could be a valuable lesson for other first-time founders looking to avoid the same mistake.

Watch the face, not the words is genuinely the hardest thing to learn when you're not from a sales background.
My version of this: assumed people would care once they saw the problem clearly laid out. They didn't. Turns out seeing a problem and feeling it are completely different things.

Watch the face, not the words is the validation insight most digital product founders skip because they default to async surveys and polls instead of sitting with a real user.

The equivalent pattern for SaaS targeting service businesses: the specific incident is the unit of validation, not the category of problem. 'I need better client communication' sounds like a real pain point. 'Client disappeared after I sent the invoice follow-up' is a moment you can build a product around. If interview subjects can't name a specific incident - date, client, what actually went wrong - you are probably hearing a complaint category, not a real recurring bottleneck.

Your riskiest assumption framing is the right one. What single assumption, if wrong, kills the whole hypothesis? Test that first, before writing a line of code.

Love the breakdown. It is the reality for the first time founder. I also made this mistake. They don't validate before they build. Also most of them are not came problem first, they came out solution first. After getting the idea they start building, no customer interviews, no customers feedback, no validation. After spending lot of month and time they realise it. First of all they should start with the Demo-Sell-build strategy. I use this formula. Sell before you build. If people buy and show interest then build the product.

Your point about watching the face not the words is gold. Had a very similar moment building aisa.to (AI skills assessment tool). Our most expensive assumption was that people wanted a score at the end. Like a number or a badge. So we spent weeks building scoring rubrics and certification flows.

Turns out what actually got people to come back was the conversation itself. The assessment was just the excuse to have a useful back and forth about how they actually use AI day to day. Someone literally told us 'I don't care about the number, the conversation taught me more about my gaps than any course.'

Would've saved a month if we'd just let 10 people talk to a rough prototype before designing the whole scoring system. Validation doesn't have to be fancy, it just has to be real.

Really appreciate you sharing this, Suhail. The "free users lie, paying users don't" line is brutal but true.
One question for you: When you finally sat with those jewellers after building, what was the most common thing they actually needed that you hadn't considered at all? Like something completely outside your original assumption set.

The build-first trap also shows up in freelancing - just with a different label.

Instead of building a product for an imagined customer, you build deliverables for a client's 'vision' that was never actually written down. The spec exists in someone's head. Three revision rounds later, everyone's frustrated, nobody can say why, and the client thinks you're a bad freelancer when really the problem is the brief never existed.

The fix is the same as what you're describing: validate the spec before you build.

For freelancers, that's a structured intake document - exact deliverables, revision limit, what 'done' looks like in writing, signed off before work starts. The awkward conversation about scope 4 weeks in is 10x worse than the 10-minute conversation about scope at the start.

The minimum viable validation isn't a landing page. It's a clear answer to 'what are we actually making, and how will we know when it's right?'

Most expensive assumption: thinking distribution starts after the product is “ready.” The earlier test is whether a painful enough user will take an annoying workaround, pay a tiny deposit, or give you a real intro before the polished thing exists.

The build-first trap usually comes with a specific cognitive error: you mistake 'I understand the problem deeply' for 'I know people will pay to solve it.' These are two completely separate things. The fastest validation loops I've seen work aren't just talking to users -- they're testing the payment decision specifically. Not 'would you use this' but 'would you pay $X for this today?' The delta between those two answers is where most failed products live. The other variable is: who else is already solving this problem, even imperfectly? If someone is paying for an ugly, half-working solution to the same problem, that's stronger validation than 100 users saying 'yes I'd use a better version.' People paying bad money for a bad solution tells you demand exists. People telling you they'd use a hypothetical good solution tells you almost nothing. What did your first real validation signal look like -- the one that told you the problem was real enough to build?

This is a very real founder mistake.

I’m going through this now with a small digital product. The product is built, but the real lesson is that building the tool is only half the work. The harder part is validating the exact pain, the language customers use, and where they already look for help.

If I were starting again, I’d spend more time collecting problem statements before polishing the product.

Build first, validate later is seductive because it feels like progress. Every hour you're coding, you're 'working.' Validation - talking to people, getting signal, sitting with uncertainty - feels like procrastination even when it's the actual work.

The reframe that shifted things for me: validation is just building with a different material. When you write a comment, send a cold message, or post a landing page with no product behind it, you're building a model of demand. That model is more valuable than the feature you would have built instead.

I'm running a live example of this right now - validating a Solopreneur Notion OS (6 linked databases: CRM, projects, revenue, client portal, decisions, weekly review) purely through IH comments before I build anything. Each comment tests a different positioning angle. The ones that get engagement or questions tell me which pain is real.

Gate is May 22 - 50 upvotes or 20 email signups to proceed. No code written yet.

What was the moment you realized you'd built without validating - was it a specific user conversation or more gradual?

The 'watch the face, not the words' advice is the most underrated thing in this post.

My most expensive wrong assumption (still testing it): 'solo founders at $0-5K MRR feel their ops chaos acutely enough to pay to fix it.'

I'm validating a Notion OS right now -- 6 linked databases for solo founders (clients, projects, tasks, revenue, content, weekly focus -- all connected). The assumption is that someone running a consulting or freelance business at early MRR is drowning in scattered context and would pay $29 for a pre-built linked system.

What I'm finding: everyone says 'yes this is my life' when I describe the problem. The ops fragmentation is real. But following your exact framework -- 'when did you last feel this problem?' -- I'm not yet sure if the pain is sharp enough at this stage, or if people have learned to live with it the same way they've learned to live with a cluttered desktop.

Your point about 'free users lie, paying users don't' is the gate I'm using: running a 7-day poll before building, looking for people who actually want to pre-order.

The lesson I'm applying from your mistake: don't build the 6 databases until I've confirmed the riskiest assumption. Mine is 'they'll actually USE a structured system' rather than fall back to their old messy habits anyway. That's the face-not-words test.

This is a strong lesson because the real risk was not whether AI could generate jewellery visuals. The real risk was whether jewellers would trust those visuals enough to use them in front of real buyers. That is a much harder problem than product quality, especially in offline Indian markets where people may praise the demo but still avoid paying.

For JewelViz, I’d probably position around trust and sales confidence, not “AI jewellery visuals.” The buyer does not care that it is AI. He cares whether the image helps him sell faster, show more designs without inventory, and avoid looking fake in front of customers.

One thing I’d watch is the name JewelViz. It explains the function, but it also feels a bit tool-like. If this grows into a premium visual commerce layer for jewellery brands, a polished name like Auryxa.com may fit the category better because jewellery needs trust, beauty, and premium perception from the first impression.

This is solid advice. "Watch the face, not the words" is something most founders learn too late. The ₹199 test is smart — free signups mean nothing, even a small payment filters out real interest from politeness. My most expensive assumption was thinking developers would find my API through documentation alone. Turns out nobody searches for your product — you have to go where they already are and show them the problem you solve. Learned that after launch, not before.