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
The replies suggest validation isn't one yes/no signal. A deposit tests willingness to pay, repeat use tests whether the problem returns, and a reply asking for more tests whether the first result was useful. I'm currently starting with useful written conversations because I don't have enough demand evidence to ask for money honestly yet. After reading these responses, which signal would you require before building the next month of a product?
I’m taking the “build first, validate with real users” route.
STOCKELY PRO started from a real-world need, and what began as a simple solution gradually became a much bigger product idea.
I haven’t taken any pre-orders yet. Right now, I’m focused on building a solid foundation and preparing the beta so I can get real users using it and learn from their feedback.
I think pre-orders can be a powerful signal, but for some products, real usage and feedback can be just as important at the early stage.
Curious to see how others here balance building, validation, and pre-selling.
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?
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
I took the build-first route with my first consumer product. For something like a dating platform, I’m not sure a pre-order would have been the most meaningful validation signal.
At this stage I care more about behavior: will people actually create a profile, complete the experience, come back, and engage with the people the product surfaces for them?
I’m learning that “will someone pay?” and “will someone actually use this?” can be two very different validation questions. For consumer products, I’d rather prove the second one first and test monetization once there’s real usage.
Curious if anyone here has taken that approach with a consumer or marketplace product.
I’m building REZYCO: https://rezyco.com
Yes, getting paid before building the full product is possible, especially when the customer has a clear problem and sees value in the proposed solution. Some founders validate demand through paid pilots, preorders, deposits, or small initial projects before investing heavily in development. This approach can reduce the risk of building something nobody wants. The key is to clearly define what the customer is paying for, agree on the scope, and deliver enough initial value to justify the payment.
Ship-first, and I'll be honest that it hasn't paid off yet. I wrote up 180 failed U.S. VC meetings as a $19 ebook with no presales, betting that non-U.S. founders about to raise already exist and will find it through search. Zero sales so far.
The irony is the book's core lesson: investors kept asking who actually pays us, and we had no answer. A deposit from one real customer would have been the answer to the question that ended most of our meetings. If I did the book again, I'd sell the free chapter for an email first.
Product page: https://www.indiehackers.com/product/the-failed-u-s-fundraising-journey
Ship-first here, and the unglamorous version of it. I put a price of about a dollar on something very small and published it as a demand sensor rather than as a product. At about two and a half months in: low hundreds of views across the account, a few likes, zero sales.
The price was the least interesting part. The useful part was writing down what the number would mean before I charged. alexfleet's point about precommitting what evidence changes the roadmap is the one I would extend. Most of the advice here (scope the pilot, define the success metric, set a decision date) describes the branch where somebody pays. AnchorsLab covers the other branch with "if nobody pays, ask what stopped them", which works when there is someone to ask. A cold zero has nobody to ask. It reads as "the problem isn't real", or "the price is wrong", or "the offer is wrong", or "nobody saw it", and if you don't pick in advance which reading counts, you will pick the flattering one afterwards.
Mine is honestly a weak instrument. At low hundreds of views I can't rule out the "nobody saw it" reading either, which is the same objection you put to the four-discoveries-a-month case further up. But I did pick which question it was answering before I ran it, so I know which reading I'm allowed to take from the zero and which I'm not. That is the part worth keeping.
So if you're tallying these answers, I'd add one column next to pre-sell vs ship-first: did the person decide, before charging, what a zero would have told them. Without it the pre-sell rows grade higher than they deserve, because the people who got a yes never had to read a zero.
A useful middle ground between presale and build-first is a concierge pilot: define one narrow outcome, charge a deposit, and deliver it manually with a decision date. The important part is precommitting what evidence changes the roadmap—repeat purchase, time-to-value, or willingness to refer—so a payment isn’t just a one-off favor. For self-serve products, even a paid setup session can expose onboarding gaps.
Shipped first, no preorders. BuilderBench is deliberately a tiny free version of the idea: founders play 8 quick events, one all-round score decides the top-five SaaS links, and the validation is whether makers care enough to compete for earned visibility instead of another static listing: https://www.buildersbenchmark.com/ If the leaderboard gets repeat attempts, that is a stronger signal than polite launch feedback.
The split between validating demand and validating access to it is the part I would keep. A pre-order can prove willingness to pay, but only among people who can find and trust the offer. How would you rank a small deposit, a scheduled workflow review, and repeat unpaid use when you have no existing audience?
A paid pilot is a useful middle ground: define one painful workflow, deliver it manually if needed, and charge for the outcome before building the full system. The strongest signal is not just a yes—it’s whether the buyer will commit a date, budget, and access to the people who use it.
Shipped first, then went looking for the yes. I built TurnKey Directories, a WordPress plugin for launching business directories (listings, categories, owners claiming and managing their own profiles). The validation order I'm running for the first five customers is the reverse: hand-picking people who are actively trying to launch a business directory and offering founder-assisted onboarding instead of a checkout page. Early signal: the ones who reply never ask about features - they ask how fast they can get their first listings in. For everyone else who shipped first: how did you find your first ten people to talk to without an audience?
Not a presale, but a middle path I'm building into my own small SaaS products: ship a free, no-signup tool that answers the exact search someone types when they have the problem, then measure what share of visitors take the next step (email, signup, paid plan).
It splits two signals cheaply. Usage tells you the demand exists. The click-through to the paid ask tells you whether they'd want you specifically. And it works without an existing audience, which is usually the real blocker for a first-time founder.
It also gives you a list of real people to follow up with, which helps with the "no references" problem that came up in this thread.
For a true paid signal, I still think doing the service by hand for five people first beats everything else, if the product can be faked that way.
Shipped first, no presale. But I would split "validation" into two questions that tend to get conflated in these threads:
Does the demand exist? Often measurable without talking to anyone. I pulled the catalogue of the marketplace I was targeting - 13,214 listings with usage stats - and could read demand per niche straight off it.
Will they pay ME specifically? Not measurable that way at all. This is where I now think presales actually earn their keep.
I got the first one right and skipped the second. Result: the product is live, priced, working, and has made exactly $0 so far, because I have zero reviews while the incumbents have hundreds of thousands of runs. The demand was real. My access to it was not.
What I would do differently is not a presale exactly - it is closer to what BlackLabelTec said about preselling a manual service. In my niche I could have offered to run the queries by hand for five people at $50 before writing a line of code. That tests willingness to pay AND leaves you with five references, which turns out to be the actual bottleneck.
Building took a day. Getting the first customer is the part I underestimated by an order of magnitude.
Preselling is one of the hardest things to get yourself to do — feels fake until someone actually pays. But that first real payment changes everything. It proves the problem is painful enough that someone will reach for their wallet before the thing even exists.
Depends heavily on the market.
In B2B, you can definitely presell an outcome, a manual service, or a spreadsheet.
In B2C or Micro-SaaS, almost never. People want instant gratification, not a roadmap. If they can’t use it 10 seconds after checkout, the conversion rate plummets. Had to ship first.
No, and I wish I'd tried. I built for two months in silence and only
started talking about it after launch. If I'd shown even a rough
version early I'd at least know whether the thing people say they want
is the thing they'd pay for.
Shipped first, no validation before building — built the whole thing, then started trying to figure out if anyone actually wants it. leaseai.rentals. Lesson learned: for the next thing I'm doing a landing page + email signup before writing any code."
Preorders can be useful, but a paid pilot is often a better signal for digital products: define one narrow outcome, deliver it manually to 3–5 users, then productize only the repeated steps. It also surfaces onboarding and pricing objections early.
Shipped first, no pre-orders. Roughly three months of dogfooding an AI analytics tool before anyone paid, and that sequencing cost me: 'it's shipping' felt like progress while demand was untested.
The signal I trust now isn't a deposit or a waitlist, it's repeat use I didn't ask for. Someone opening the same view the next week with no nudge from me. That costs them something, which is the closest thing to a deposit I've found, and it still isn't willingness to pay. The two split the first time we put a number on it.
If I restarted: build the smallest thing a stranger uses twice, then quote a price before building anything else. Where I found those strangers, since you asked: analytics threads where people describe the exact reporting pain, replying as myself instead of pitching. Product is https://amami.dev
Honest counter-example: I shipped first. I built the whole product (an accessibility scanner) in about 3 weeks, sold to nobody, and it joined several of my earlier products sitting at $0. "Shipped" felt like progress while demand was completely untested.
What I do now instead of pre-orders: I send strangers something small and free that already solves their problem, and treat any reply as the signal. "Sounds cool" costs nothing. A reply asking "can you send the rest?" costs a minute of someone's time, which is the smallest real price I've found. It's not a deposit, but for me it beats a waitlist by a mile.
Still $0 revenue, so take this as a data point on what not to do, not a success story.
The gap between "that sounds cool" and "here's $500" is where ideas actually die. Pre-payment captures conviction in a way surveys can't - your measurement system either trusts deposits or it doesn't. Most founders measure interest when they should measure deposits.
I'm testing a new offer on an existing product: sponsorships in TranslateMom's translated video replies. The bot and auction are built, but the sponsorship month hasn't started yet. Four brands have put down $250 each.
The caveat is that an outbid bidder gets a full refund, so I wouldn't call that $1,000 of finalized revenue or proof of repeat demand. It tells me people will pay for a clearly described placement. Whether they want another month is still untested.
For this kind of validation, I'd keep money committed, money refunded, and repeat purchases separate. They answer different questions.
shipped first, charged immediately. the signal I trusted wasn't "would you pay for this?" — it was whether the first 5 people kept using it after the novelty wore off. verbal interest means almost nothing because people are polite. credit card retention is the only validation that doesn't lie to you.
Third option: sell the outcome before the system exists.
When a founder describes a workflow that's painful enough, we scope a paid engagement to make it go away, then build and operate the system behind it. The deposit is the validation. Nobody pre-pays for a workflow that isn't actually hurting, so the signal is cleaner than a waitlist.
The catch is it only works if you can deliver what you sold, so we scope narrow and stay on after launch instead of handing over a repo and leaving. Build-first and pre-order both make sense for product plays, but if what you're really selling is a result, charging before you build is the most honest validation there is.
This question hits different because most people skip it entirely. Pre-paying customers are your real validation — everything else is just feedback. Love that you're pushing builders to find out before they build. Keep it up!
The point about a verbal yes vs. an actual deposit is the one people gloss over most. In my experience even a small deposit changes the conversation completely — people start asking sharper questions about the product once their own money is on the line, which is feedback a waitlist signup never gives you. I'd guess your audience variable matters more for speed-to-first-sale than for whether pre-selling works at all — cold pre-sells still convert, just much slower and with way more follow-up needed.
The pre-payment signal is so clear because it's binary - they either put money down or they don't. But what's underneath that? It's conviction measurement. The founders who get deposits are measuring something different than the ones shipping first: they're measuring whether a prospect will sacrifice something material (money, time commitment) for what you're building, not just express interest. The gap between "yes that would be cool" and "here's my card" is exactly where most ideas die. Measuring at the wrong stage lets you confuse interest for intent.
Not yet, no. I just launched mine and I'm in the exact position of needing to prove it's useful before anyone pays for it. Curious how long it took others here to get their first paying (or even just active) user after launch — feels like the hardest part right now.
I’ve found the best signal is not a generic pre-order page. Ask a small number of people who already feel the problem to commit to a narrow outcome. A paid pilot or refundable deposit is useful, but only if the scope, delivery date, and refund conditions are explicit.
If nobody pays, ask what stopped them and change the offer before building more. If the problem is urgent but payment is hard, start with a manual service and watch what they repeat. That gives you real usage and language for the product. Ship first can also work when you have a tight feedback loop, but set a date for asking for money so beta users do not become a permanent free tier.
I seem to have taken a different approach that some, building Enlive before I got anyone to pay for anything. Personally, I have a hard time paying for something before I understand its value or have used it before.
I had to build the platform before people could use it and understand the problem it solves, and this is something I am continuing to validate now. I do agree that getting any kind of commitment in dollars up-front is preferable, but this isn't always an option.
Enlive helps people manage and reuse relevant context from the email, files, and prior work they control across many AI models they already use, allowing better AI replies and less time spent prompting and re-explaining. I’m testing whether the automated setup creates enough value to justify the access, and need a small cohort of beta testers.
Enlive:
https://www.enlive.inc
I can message anyone who is interested or comments. Thanks.
Hii everyone I'm new here. Can anyone help me how can I do post like you people
Maybe angel investor
"Spot on! Compliments or saying 'I would use this' is one thing, but when you actually ask people to pay, it completely changes the conversation. That's the ultimate validation!"
The three-way framing hides a big gap: a verbal "yes" and a real deposit are completely different signals. The only pre-build commitment that ever predicted revenue for me was money that stung a little - roughly 10-20% of the eventual price, invoiced manually, not a waitlist signup. The other variable nobody separates out is audience: pre-selling works when you already have a warm channel (a list, a community you're genuinely active in, past clients), and it quietly fails cold, which is why a lot of "we validated first" stories are really "we had distribution first" stories. The middle path that's worked best for me is shipping a deliberately narrow version to 5-10 people who already trust you, charging immediately even if the price feels embarrassing, and treating the first refund request as the actual validation event. When you tally these answers, are you going to segment them by whether the founder had an existing audience before they pre-sold? I'd bet that variable explains far more of the outcomes than pre-sell vs. ship-first does.
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
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?
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.
At four visitors a month, I'd try a small direct test before spending more time on broad discovery: find 5–10 site owners already asking for help with technical SEO, offer to run their site through the free audit, and walk through the top three issues with them.
Then ask what they'd actually use the paid version for. A one-off audit and ongoing monitoring are different purchases, especially with annual pricing. That should help separate 'people aren't finding it' from 'the free scan is enough' without needing a big audience first.
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?
I’d expand when the same paid outcome repeats without inventing new scope each time. I’d stop when the buyer keeps asking for one-off custom work or won’t reuse the same success metric.
— 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?
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.