Did anyone actually pay you before you built the full product?
Quick validation check for makers 👇
- Did you get a yes / pre-order / deposit before building?
- Or did you ship first, then sell?
- Drop your product link + how you validated
Looking for more indie eyes?
https://www.indieneed.com/submit
No, and the honest answer is that six months after shipping, still no. The product works — a free SEO audit runs 2,000 pages against 100+ ranking factors in about 30 seconds, no signup. Paid tiers are £400/yr and £1,490/yr. The tool is real. The problem is not validation of the product; it is that roughly four people per month discover it exists.
Every comment here assumes the bottleneck is product-market fit or willingness to pay. For us, the bottleneck is discovery. DA 3, ten referring domains and every one of them is a scraper. We would need someone to actually find us before we could learn whether they would pay.
Pre-payment validates demand, but only if the people with the problem can find you. If I did this again, I would build distribution before the product, not after. Get the audience first, ask what they would pay for, then build. We did it backwards and now the validation question is stuck behind a traffic question.
That sounds like a distribution problem before it’s a product problem. Four discoveries a month isn’t enough data to judge willingness to pay, so building a small audience or a few repeatable acquisition channels first makes sense. Since you’re looking for discovery, you can also submit the tool here: https://www.indieneed.com/submit
A pre-order signals urgency, but the learning really starts when the delivery promise is explicit: scope, success criteria, and what happens if the manual pilot misses. Did you set a refund or conversion checkpoint before taking deposits?
That makes sense—the pre-order tests urgency, but a clear delivery checkpoint is where expectations become real. A refund or conversion checkpoint up front sounds like a smart way to keep both sides aligned.
I got the clearest validation from a narrowly scoped paid pilot, not a vague pre-order. I asked one business to let me solve one measurable support problem for 2 weeks, with a manual fallback if the prototype failed. The useful part was defining the success metric up front (fewer repetitive questions / faster answers) and charging for the pilot; the conversations exposed which edge cases mattered before I built the broader product. A “yes, if you can solve this exact workflow” is much stronger than a generic “I’d use it.”
A narrowly scoped paid pilot is a much stronger signal than a general promise. Defining the deadline and success metric before building also gives you a clean decision point for what to expand.
I’ve found the most useful “yes” wasn’t a pre-order, but a narrowly scoped paid workflow with a clear deadline. It forced a concrete success criterion and exposed onboarding gaps before I polished the rest. If people won’t pay yet, ask for a smaller commitment—calendar time plus access to real inputs can still validate urgency.
That’s a good point—asking for a smaller commitment can keep the validation honest when a full payment is too big a leap. Even a scheduled pilot with access to real inputs should tell you whether the problem is urgent enough.
Exactly—real inputs plus a clear success criterion gives you useful evidence without pretending the full product is ready. I also like setting a decision date upfront; it keeps a small pilot from turning into an open-ended custom build.
— Cameron M Deans
No, but I knew that https://tempmaildetector.com would be a useful product, based on the following:
So no, but also if you enter in to an existing market, then do better than the rest - it's definitely possible to validate that way.
Now we're moving towards full email detection with trained models (not LLMs), and it's looking super promising. So eventually we'll be able to give a good indicator as to whether a gmail - which is a legitimate email domain - is likely to be disposable or not. A little more work to be done there :)
That’s a solid way to validate: enter an existing market, then prove you can beat the current options on a measurable outcome. Since you have a live product, you can also submit it for free discovery here: https://www.indieneed.com/submit
Yes, twice actually.
First time was before writing a line of code. I had a problem I knew others had, ran it by a few people, and one of them asked how much to get early access. That was the signal I needed.
Second time was different. I had a working product, could demo it, and still couldn't get paid. Not because the product was wrong but because I was leading with features instead of asking people what outcome they'd pay for. The shift was asking "what's this worth to you if it solves X?" instead of "here's what it does."
Pre-payment without a product is mostly a consulting mindset applied to product. You're not selling software, you're selling the certainty that the problem gets solved. The people who say yes before you've built anything are usually the ones with the most acute pain, not the most optimistic dispositions.
What's prompting the question — validation stage or post-launch reflection?
That’s a great distinction. A paid pilot gives you a real commitment and a concrete set of expectations to build against, which is much stronger than a vague “I’d use it.”
Pre-orders can be useful, but I’ve found a short paid pilot often gives better signal than a promise for a future product. The key is asking for a real commitment from the same type of user you plan to serve, then writing down what they expected before building. That makes the eventual scope much easier to prioritize.
Yes, a paid pilot seems like a much cleaner test than waiting for a full launch. It also gives you a chance to learn what people actually value before committing to a bigger build.
I'm trying to get more eyes on my product before I do anything with it. I would love to see more people interested/shre in the vision that I have before I venture out.
That’s a strong example of selling the outcome first. Doing the work manually also seems like a great way to learn the workflow before turning it into software.
Yes, and the version that counts is not a pre-order, it is someone paying for the outcome while you deliver it by hand. Henson Group started with me doing migrations manually for companies in New York before there was a company, and those invoices told me what to build in a way no survey ever would have. When I look at deals now I want to see $1,000 MRR or 100 customers before I write a check, and the founders who charged first almost always get there faster than the ones who shipped first and then went looking for a buyer.
Six pre-delivery sales is a strong validation signal. Getting commitments before building can make the scope much clearer—nice work finding that demand early.
I got 6 sales before actually delivering the product.
I built https://PressDrop.io - get your startup on the news, tell the internet u exist!
Validating your product before building is super important IMO.
Absolutely—getting a few real commitments before building can save a lot of wasted effort. It also tells you which problem is urgent enough for someone to pay for.