Before I start
I’m a indie hacker. Years of engineering work trained me to be a certain kind of person: someone who can ship a product efficiently, who wants every question reasoned through before touching the keyboard, and who believes you don’t get an opinion until you’ve done the research.
I always thought these were strengths. Then I started building my own product, and I found out they can quietly work against you. On the startup path, they sent me down a long detour and cost me two wasted months.
Later I saw the real root of that detour. It wasn’t a technical problem. It was one small thing I kept avoiding: asking a real person to pay me. To dodge that single moment, I was willing to bury myself in two months of product work.
This post is an honest record of how I got it wrong, step by step, and what I’d do differently if I started over. If you’re an indie hacker, or you’re about to validate a business idea of your own, I hope my detour saves you some time.
A validation plan I thought was clever
In May, I built an AI tool. Going in, I was clear on one thing: don’t build in a vacuum. Confirm that someone actually needs this first.
So I picked a forum where programmers and product managers hang out, and I posted a link to the product. Because I was worried the early version wasn’t polished enough, I didn’t charge for it. Instead I dressed it up as an “early access beta” and handed out 100 free credits.
Here was my thinking:
- If a lot of people showed up and liked it, that meant there was demand, so I could keep investing and later ship a paid version.
- If nobody cared, that meant there was no need, and I’d cut my losses early.
Looking back, I’d thought through every step of this plan carefully. But the one step that mattered most, I got wrong.
A month later, I was left with a report card I couldn’t read
After launch, I opened the dashboard almost every day just to check the number. By the end of the first week, there were fewer than ten trials. I’d expected at least fifty. The gap hit me harder than I’d braced for. For a few days I’d glance at it, close it, then find myself opening it again minutes later. The number didn’t move, and my mood kept sinking.
By the one-month mark, it had crept to just over twenty, and a good chunk of those were people I actually knew.
What bothered me most wasn’t that the number was low. To build this tool I’d spent two weeks developing it, then close to a month on marketing and promotion. Add the month I spent waiting for feedback, and I’d sunk a full two months into it. Yet the report card I got back couldn’t tell me anything useful.
Where was the problem, exactly? Was there no real demand? Was the product not good enough? Or was my marketing just not landing? I stared at those twenty-odd trials and couldn’t reason my way to an answer.
Later I told the story to a few founders further along than me. After those conversations, it slowly dawned on me: the report card wasn’t the problem. I’d designed the whole experiment wrong from the start.
I thought I was validating demand. I validated nothing.
What I actually wanted to know was whether anyone would pay for the product. But by testing with free credits, I measured something completely different: whether anyone would click to try it for free.
Those two things sound alike, but they play out very differently, and they’re often two different groups of people. Someone willing to try it for free is not the same as someone willing to pay. Between the person who clicks “take a look” and the person who opens their wallet, there’s a wide gap.
Once that clicked, I saw the natural but dangerous assumption I’d been making: I’d treated traffic as revenue. How many times the free credits got used has almost nothing to do with whether the business works. A free or dirt-cheap price often only validates a moment of curiosity. In situations that hinge on trust, “free” can even make people assume the thing probably isn’t worth much.
The reason I reached for “free” without thinking was that I’d absorbed the big-company playbook: pull in a huge crowd with something free, then filter out the small slice willing to pay. But I’m a one person company. I don’t have that kind of traffic, and I can’t afford to burn cash that way. That logic simply doesn’t apply to me.
Worse, whether the number was twenty or thirty, it couldn’t answer the one question I cared about: if the result was disappointing, was it because there was no demand, because the product wasn’t good enough, or because the marketing fell flat? A month of waiting bought me nothing but a number I couldn’t interpret.
Looking back now, choosing “free” was really me choosing the one path where I’d never have to ask anyone for money.
Pricing was the thing I was really avoiding
There was another reasonable-sounding excuse for not charging: I didn’t know what to price it at. I couldn’t find a comparable paid product on the market (it probably exists, I just hadn’t found it), so I told myself I should first see how many people used it, gauge how popular it was, and back out a sensible price from there.
That order, I now see, is backwards.
Pricing is part of the product itself. Whatever number I put on it tells the market what tier of thing this is. That’s a call I have to make on purpose. It isn’t something the data can calculate for me.
“Let me figure out the pricing properly before I charge” sounded rigorous and fit my usual way of working. But honestly, it was a disguise. It let me put off the move I was actually afraid of: asking a specific person for money and being ready to hear no. Swapping “I’m not ready yet” in for “I’ll do it right now” was the most comfortable choice at the time. Only later did I see it was also the most expensive.
Here’s what I eventually accepted: there’s no such thing as objectively right or wrong pricing. The only difference is whether someone buys. No competitor doesn’t mean you can’t price something; having a competitor doesn’t mean you can just copy theirs. It’s not a complicated idea, and it still took me two months to hear it.
One sentence from a user snapped me out of it
There was a deeper reason I was afraid to charge: I kept feeling the product still wasn’t good enough.
While I was waiting for results, I couldn’t sit still, so I rebuilt the product’s interface and technical architecture from scratch, which ate up another two weeks. Maybe it was because other people’s sites all looked so polished, or maybe I just lacked confidence in the product itself, but a voice in my head kept insisting: make the interface a little prettier, polish it a little more, and users will be more willing to pay.
That instinct was the most subtle mistake I made. I’d quietly assumed that to get someone to pay, I first needed a flawless product.
The thing that snapped me out of it was one sentence from a user. He said:
“I don’t have time to run it myself right now. Could I just send you my data, you run it, and send the results back?”
I froze. It suddenly hit me that to validate demand, I may not have needed a full website at all. All I really needed were three things: a price I dared to say out loud, a way to get paid, and the ability to deliver the result by hand once someone paid.
In the earliest days, doing everything manually would have been more than enough. If someone pays, the demand is real. If nobody pays, I’d have saved the two months I ended up throwing away.
What I was really afraid of was rejection
When I was honest with myself and peeled back the layers, I finally reached the fear underneath it all.
Asking someone for money has always been hard for me, so I could always find an excuse to put it off. The reason I gave out loud was that the product wasn’t polished enough and charging too early wouldn’t be fair to users. But the reason I didn’t want to admit was simpler: I was afraid of being rejected.
What I wanted was approval, that “this product is really good” kind of validation. In my head at the time, being rejected equaled failure, so I’d rather keep preparing forever than actually go ask.
After talking with a few founders who’d already made it work, I rethought what “rejection” even means.
One of them pointed out that a paid experiment exists to collect an answer, not applause. And rejection is a very clear answer. If I’d spoken up sooner, even ten people telling me “thanks, but not right now” would have shown me within a week that the demand wasn’t there, saving me all the time I later poured in for nothing.
A simple “no thanks” completes a valid test. It isn’t failure. Once I understood that, I realized what I’d been missing was never ability. It was the nerve to face a real customer, and the readiness to take a no.
Closing thoughts
For an indie hacker, the biggest opponent early on usually isn’t a technical challenge. It’s that knot of fear about being rejected. As for what it actually takes to validate a business idea, it’s far simpler than I once thought: a price, a way to get paid, and one conversation you’re brave enough to start. That’s a week’s worth of work, not two months.
If these two months taught me one thing, it’s this:
Stop hiding behind your product. Go talk to your customers.