A SaaS product is software that customers use online for a recurring subscription. The cheapest route to your first paying customer starts with proving people will pay, then building the smallest version that serves them. Building the whole product and then looking for buyers means paying for every feature before you know anyone wants it.
This article gives you a four-stage test you can run before writing a line of code, with a go signal and a stop signal for each stage. The counts here are starting points we suggest, not research findings. Set your own numbers before you begin, so you don't read the results in favor of your idea.
How to test the idea before writing code
| Stage | What you do | Go signal | Stop signal |
|---|---|---|---|
| 1. The problem | 10 to 15 conversations with people in your target group | They can say when the problem last happened and what it cost in money or time | They say "nice idea" and can't give an example |
| 2. The promise | One page explaining the outcome and the price | Some accept a binding step: a meeting with the decision maker, or a deposit | They ask you to let them know "when it's ready" |
| 3. The manual service | You deliver the outcome yourself for a few customers, using spreadsheets and existing tools | They come back next cycle and ask you to continue | They stop after the first round, even when it's free |
| 4. The smallest version | You code the step that ate the most of your manual time | They pay, and use it without reminders | They pay once, then vanish |
Stage 1: ask about the past, not your idea
The strongest early evidence is people paying today to solve the problem badly: a staff member, an outside service, or a day lost each week in spreadsheets. If nobody is spending money or effort on it, you're trying to create a new habit, which is harder and costs more.
Skip "would you use this?" because politeness answers for them. Ask about what actually happened:
- When did you last face this problem, and what did you do?
- What did that cost you in money or hours?
- What have you tried that didn't work?
- Who decides on a purchase at your company, and from which budget?
The Mom Test by Rob Fitzpatrick is a whole book on these conversations and how to avoid misleading answers. Talk to strangers in your target group, since your friends will cheer you on whatever the idea is.
Stage 2: present the promise and the price
Write one page: who it's for, the outcome, the monthly price and the start date. Then show it to the people you spoke with. As a hypothetical example, take a tool that reminds car workshop customers about service dates, priced at 50 currency units a month. Ask the workshop owners to commit to a trial next month with a deposit.
Asking for commitment reveals what questions can't. An owner may call the idea excellent, then hesitate at the first request for money. That hesitation tells you something useful about the price, the promise or the person you're talking to.
Stage 3: deliver by hand before you code it
Do what the software would do, yourself, for your first group of customers. In the hypothetical example, send the reminders by hand from a spreadsheet for a month. You'll learn what customers really ask for, what they ignore, and which step takes up your time.
Paul Graham's essay "Do Things That Don't Scale" argues for this approach. He writes that early users rarely arrive on their own, so founders have to go and get them. He describes how Stripe's founders set the product up for users on the spot, and how they did by hand, behind the scenes, some of what appeared automated. The goal is learning, and the manual work ends once you know what deserves code.
Stage 4: what do you build in the first version (MVP)?
Build the repeated step customers pay for, plus only what it needs to run: login, basic permissions and a way to pay. Cut features and keep what remains reliable. Customers accept a short list more readily than a bug that loses their data.
Before coding, check that the product deserves building at all. If ready-made tools already solve this problem well for your group, read our comparison of off-the-shelf and custom software through your customer's eyes, because they'll ask the same question about you.
Technical decisions that are hard to change later
Some decisions look small at the start and cost a lot to change once customers pile up. Raise these with your development team from day one:
| Decision | What to ask |
|---|---|
| Isolating customer data | How do we make sure one customer never sees another's data? OWASP's guidance compares separate databases with shared tables: the first gives stronger boundaries at higher running cost, and the second depends on how accurate your controls are |
| Plans and prices | Are they stored as data you can edit in an admin panel, so a price change doesn't need a software release? |
| An audit trail | Can we see who changed what and when, if a customer asks about a number that moved? |
| Usage limits | Are there per-customer limits, so one customer's usage can't affect the rest? |
| Data export | Can customers take their data if they leave? A buyer may ask this before subscribing |
How do you get your first payment?
Ask your very first customer to pay, even at a time-limited trial price. Free use doesn't test your biggest assumption. You don't need a full subscription system at this point either: a payment link from a gateway that works in your country, or a manual monthly invoice, will do for your first customers.
Tie the price to something that grows with customer value, such as users, branches or usage volume. Start at a price you can defend by what the product saves, because a low price set out of fear may not cover the cost of serving and supporting customers. Work out your customer acquisition cost early as well, since a monthly subscription pays that cost back over several months.
Before your first invoice, ask your accountant about tax obligations where you operate. In Saudi Arabia, for instance, the Zakat, Tax and Customs Authority runs e-invoicing in phases, according to its official page in November 2026. This is a pointer and not tax advice.
The number to watch after your first customer
Watch how many customers are still using the product a month later, since sign-ups alone tell you little. As a hypothetical example, if ten paying customers sign up and seven are active after a month, talk to the three who stopped and ask what they expected. If people sign up and disappear, advertising will only raise the number who disappear, so fix the product first.
Common questions
Do I need a technical partner from the start? Not for the first two stages, which are conversations and a single page. The decision matters at the first version, when you need someone who understands data isolation and payments.
What if the idea stops at stage one? You've lost weeks of conversations in place of months of coding. Review what you heard, since it may contain another problem worth testing.
Next step
This week, list fifteen people in your target group, write down your own stop signal, and hold the first five conversations. When the idea clears the early stages and you need someone to build the first version, take a look at PlanKit's SaaS product development service.