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
I think getting some form of commitment before building can be a great way to test whether the problem is real, but it probably depends on the product and target audience. Even a few serious sign-ups or conversations can reveal a lot before investing months into development.
For those who validated with pre-orders or deposits, what approach worked best for getting your first commitments?
I’m currently taking the early-adopter / market-validation route rather than trying to get people to pay before the product is properly validated.
I’ve built the initial version of Neural Hive, and right now I’m looking for early users to test it, give feedback, and help validate whether there’s real demand before going deeper.
Would love to hear how others here approach the pre-revenue validation stage.
Neural Hive: https://neural-hive.netlify.app
Im taking the ship a narrow outcome, then learn from real buyers” route. I just shipped a $17 AI Disruption Household Checklist: a practical PDF covering cash-runway questions, a modest 7–14 day essentials buffer, skills/work backups, household coordination, benefits questions, and a one-page action plan. I’m not claiming income results—the validation question is whether people actually use it and tell me what’s missing. I sell this PDF directly (owned product, not an affiliate link). If that’s useful to anyone here: https://buy.stripe.com/28EfZ944V6ls9db30qes005
Shipping a narrow outcome first is a sensible way to learn without pretending the full product is finished. The checklist sounds concrete, and letting buyers tell you what’s missing should make the next iteration much clearer. Since you’re sharing it here, you can also submit it for indie-maker discovery: https://www.indieneed.com/submit
AmandaBrown's line "you're not selling software, you're selling the certainty that the problem gets solved" is the sharpest thing in this thread — it reframes pre-payment as a different product entirely, not an early version of the same one.
Honest answer for me: no, StareBrain is still pre-launch, no payment tested yet. But James_UtilitySEO's distribution-before-product story is the one that's actually changing my plan — a working product means nothing if the four people a month who find it can't be told apart from noise. I've been treating validation as a build question. It might be a discovery question wearing a build question's clothes.
Yes, we got paid for the first MVP (10% of what was agreed upon for the full product).
We failed to deliver the frontend in time thanks to my partner not keeping his promises.
The idea got sold with the MVP backend.
This was back in 2016. It was a mobile phone contract finder SaaS that could find best contracts, deals and discounts. Later last year the project was killed due to losing its user base to Google, AI and search engines gettin smarter.
I shipped first rather than getting pre-orders, so this question hits home for me. I’m currently learning that building something people can use and getting people to actually discover and try it are two very different problems.
I’m curious about the people who validated with a paid pilot: how did you find those first potential customers before you had much of a track record?
That gap between building and being discovered is so real. Turning the interest into a call or workflow review can help show whether the vision solves a concrete problem; if you have an early product page, you can also submit it at https://www.indieneed.com/submit.
That makes sense. I think the workflow review part is especially useful because it can reveal whether there’s a real problem before trying to sell the product itself.
When you say turning interest into a call or workflow review, do you usually reach out directly to people who seem like a fit, or do you find them through communities/content first?
The pre-order question is a good filter, but the real signal isn't the payment itself — it's whether the person did something costly before the product existed. Money is the strongest form of that, but there's a ladder below it that's easier to get early: showing you their current workflow, booking a call, forwarding a real document, introducing you to a colleague. If someone won't do the free-but-costly thing, they were never going to pay; if they do, the deposit conversation gets much shorter. Deposit is the top of the ladder, not the only rung worth testing.
That’s a useful way to frame it. A deposit may be the strongest signal, but seeing someone invest time and access into a real workflow can reveal urgency earlier. Which of those commitments has predicted a later payment best for you?
Great questions, Rahul! Validating before building is always the holy grail, but a lot of indie makers still ship first and iterate based on real feedback. For most products, getting a pre-order or deposit forces you to prove demand immediately. How do you usually approach validation for your own projects before writing the first line of code?[cite: 7]
I try to get as close as possible to a real commitment before building the full thing: a paid pilot, deposit, or at least a concrete workflow review with the target user. The quality of the problem and the specifics of the promised outcome usually tell me more than a general “I’d use it.”
100% resonate with this. Managing complexity and staying lean is always the hardest part in the early days.
That early-stage tension is real—staying lean usually means choosing what not to build as much as what to ship. What helped you decide which complexity was worth keeping?
Shipping first can work, but a small paid commitment seems like a cleaner signal. I’m testing that with SoftShelf’s $9.99 Excel/Sheets debt payoff planner — kept it intentionally narrow (snowball vs avalanche compare, max 6 debts) so the promise is concrete. Curious whether a pre-order, paid pilot, or first shipped sale taught you the most. If useful: https://grokbear.gumroad.com/l/eqdyqi?utm_source=indiehackers&utm_medium=community&utm_campaign=first_sale&utm_content=comment
Quick link fix (username changed): https://softshelfstudio.gumroad.com/l/eqdyqi?utm_source=indiehackers&utm_medium=community&utm_campaign=first_sale&utm_content=comment_fix
A small paid pilot or a first shipped sale both seem like useful signals, but the narrow scope is what makes the lesson actionable. SoftShelf sounds like a clear, focused offer, and you can submit it for another discovery channel here: https://www.indieneed.com/submit
A paid design-partner commitment is stronger than a waitlist signup, but it doesn’t have to mean building the whole thing first. I’d sell a narrowly defined outcome, mock the workflow in a few screens, and ask for a small deposit tied to a delivery date. If nobody will pay for that slice, more features usually won’t fix the validation problem.
That’s a sensible middle ground: sell a clearly defined outcome, keep the prototype lightweight, and tie the deposit to a date. It makes the payment a real commitment without forcing you to build the whole product before learning whether the problem is urgent.
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
You have nailed it — distribution before product is exactly where we are. The four-a-month number is enough to know the tool works but not enough to learn whether people will pay for it.
Community threads are our main acquisition channel right now. Nearly every real user came from someone reading a comment with our numbers in it and running the scan themselves. That is not scalable, but it is teaching us what resonates: people care about the cost of fixing the issues more than the feature list.
I will check out indieneed.com — though our experience with directories so far is zero measurable traffic from any of them. The ten referring domains we have are all scrapers. What has been the conversion path for tools listed there: do people actually click through and try the product, or is it mostly a backlink play?
Fair question—I don’t have enough conversion data yet to claim directories reliably drive clicks, so I don’t want to oversell it. I’d treat it as one small channel and judge it with tagged visits and signups over time; your community comments sound like the clearer signal so far.
Appreciate the honest answer — that is more useful than a pitch. We will submit with UTM tags and measure it properly rather than assuming.
The community signal has been the surprise. Real numbers in comments draw replies while generic product descriptions get scrolled past. The replies teach us what people care about, and it turns out to be the cost of ignoring problems rather than the feature list. That is shaping our positioning more than any A/B test could at four visitors a month.
Worth testing whether a directory listing lets you be specific enough to attract the right click. An entry that says "SEO tool" probably performs differently from one that says "shows you which of 100+ issues is actually hurting your ranking." The conversion question might come down to specificity.
That specificity distinction is a useful hypothesis to test. “SEO tool” says what category it is, while the concrete problem statement gives someone a reason to click. Tracking tagged visits through signup should help separate curiosity from meaningful intent.
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.
Solid framing. The checkpoint I’d use: a paid deposit unlocks a scoped outline in 48h, and the full build only starts after they approve that outline. Refund the deposit if the outline misses; convert it toward the full price if they greenlight.
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
The decision date is the part I’d want to copy too. It keeps a paid pilot from quietly becoming bespoke consulting while still giving you enough time to learn. What signal do you use to decide whether to expand the pilot or stop?
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?
It’s a bit of both: I’m using the question to pressure-test the idea, while reflecting on how much stronger a real commitment is than a polite “I’d use it.” Your consulting comparison is spot on. Have you found a particular offer or promise that makes that commitment easiest to ask for?
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.
A paid pilot does feel like the cleanest middle ground: it tests urgency while keeping the scope small enough to learn. Writing down the expected outcome beforehand is a great guard against the pilot turning into open-ended custom work. How often have your pilots converted into the broader product?
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.
Getting eyes on the idea before committing to the full build is sensible. Try to turn that interest into a concrete signal, such as a call, a workflow review, or a small paid pilot, so you learn what people actually want. If you have a product page or early version, you can also submit it at https://www.indieneed.com/submit for indie makers to discover. What kind of feedback would convince you it’s ready to take the next step?
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.
That distinction between selling the outcome manually and selling software is important. Those early invoices must have made the build priorities much clearer than a survey could. When you moved from manual migrations to a product, which part was hardest to standardize?
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.
Six sales before delivery is a strong signal, especially when the promise is concrete enough for people to pay early. That kind of validation should also give you useful clues about which outcome to emphasize in the launch story. You can submit PressDrop at https://www.indieneed.com/submit if you want more indie makers to find it. What did those first buyers care about most?
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.