Insights / Product
How to Validate a SaaS Idea Before You Hire Developers
Prove a buyer will pay before you fund a build. Use interviews, landing pages, design partners, and paid pilots. Opinions are not validation.
If you want to know how to validate a SaaS idea before you hire developers, start with a sentence that can fail. SaaS means software as a service: software you sell on a subscription. The sentence is: a specific buyer will pay to replace a specific current method. Everything else — mockups, domain names, a clever stack — is decoration until that sentence has evidence. Friends will say it is clever. Strangers who pay, or who sign, are the signal.
Compliments do not convert into monthly recurring revenue. Invoices, deposits, and design-partner contracts do. This is a sequence you can start this week. It is not a lab experiment. It is sales with a notebook.
If you already have payment and usage, skip ahead to cutting the MVP (minimum viable product — the smallest product that tests the idea) — what should be in an MVP. If you are still in love with the idea and have not spoken to a buyer, stay here.
How to validate a SaaS idea: opinions are not the method
An opinion is what you get when you ask “would you use this?” People are polite. They also do not know what they would do in six months. Ask how they solve it today, what it costs them in time or money, who has budget, and what they tried that failed. Then stop talking and let them talk.
Write pass/fail before you start. Example: “I will run ten interviews with people who hold the budget. If fewer than four describe the same expensive workaround, I will not build.” If you do not write the number, you will move the goalposts after the eighth nice conversation.
Do not pitch in the first half of the interview. Pitching trains them to please you. You are there to map their current path. If there is no painful path, your SaaS is a nice-to-have. Nice-to-haves are hard to charge for.
Record the words they use for the problem. Your homepage should speak that language, not the language of your architecture. A CMS full of slogans will not fix a problem you have not heard in their voice.
Interviews that actually produce evidence
Target the person who feels the pain and the person who pays. Sometimes they are the same. In B2B they often are not. If you only talk to end users, you will build a tool nobody can buy. If you only talk to executives, you will build a dashboard nobody opens.
Ten conversations is a start, not a magic number. Quality beats volume: people who match the ICP (ideal customer profile — who you sell to), not your college group chat. Stop when you can predict the workaround and the objection. If every interview is a different problem, you do not have an idea. You have a tour.
Ask for artifacts: the spreadsheet, the inbox label, the weekly meeting. If they will not show you the work, they may not let a product into the work either.
End with a commitment request, not a compliment request. “If I ran this by hand for you for two weeks, would you pay N?” You want a yes, a no, or a specific condition. “Keep me posted” is a polite no.
This week: list twenty names or companies. Ask for fifteen minutes. Do five interviews before you touch Figma. If you cannot get five conversations, your access to the buyer is the real risk — not the feature list.
| Question to ask | What you learn | Weaker question that does not help |
|---|---|---|
| How do you do this today, step by step? | Finds the job and the glue | “Would an app help?” |
| What does it cost when it fails? | Budgets attach to pain | “Is this a big problem?” |
| What have you already paid for? | Reveals category and cynicism | “Do you like our category?” |
| Who signs and what would they need? | Maps the actual sale | “Would your team use it?” |
| Will you pay for a manual version? | Tests money | “Can I add you to a waitlist?” |
Landing pages: interest, not revenue
A page with a clear offer, a price or a range, and a way to talk to you tests whether strangers respond. That is useful. It is not proof they will stay subscribed.
Write the offer like a sales email: who it is for, what they stop doing, what it costs. Vague “reimagine workflows” pages collect browsers who will never buy. Specific pages collect arguments — which is better. Arguments mean someone understood you.
Traffic source matters. Ads to a broad audience teach you about copy. Conversations with your ICP teach you about the business. Do not confuse cheap clicks with a market.
A waitlist is a weak yes. Strengthen it: deposit, calendar booking, a short application that asks about their current tool and budget. Friction that a real buyer will tolerate is information. Friction that only your fans will tolerate is a club, not a market.
Do not hire developers because the landing page converted at a number you liked in a weekend. Hire them when the next step — a call, a pilot, an invoice — also converts.
Design partners: early buyers, not free beta users
A design partner is a buyer in the ICP who will use an early, ugly version, show you the real workflow, and usually pay or sign something that hurts if they walk away. They are not a beta user who wants free software forever.
Write what they get: influence on the cut list, attention, a price lock for a period. Write what you get: weekly usage, a named counterpart, permission to hear “this is wrong,” and money or a letter you can show the next buyer. If they want the product for free because they are “helping you,” they are a user study. Price the study or decline.
Three to five design partners beat fifty waitlist emails. You cannot staff fifty relationships. You can staff five.
Do not let design partners expand the MVP into a custom project for each of them. Their job is to represent a market. If each partner needs a unique integration before they will try, you do not have a product. You have consulting. Consulting can be a valid business. It is not the SaaS you pitched.
Paid pilots beat unpaid hope
A paid pilot is a small, time-boxed engagement where they pay to run the job — even if you perform parts of it by hand. Concierge is allowed. Software is optional. The point is money and a calendar.
Price the pilot high enough that a no means something and a yes means something. A $20 “pilot” from a company that spends $4,000 a month on the workaround is a toy. Match the scale of the pain, then discount explicitly if you must, on paper.
Write success criteria before week one. If you cannot write them, you are selling access to your time with no definition of done. That is how pilots never end and never convert.
If they will not pay for a pilot and will not sign a near-term start, believe them. Build anyway only if you are funding a learning exercise with money you can lose. Be honest about which it is.
After a pilot, you have evidence for what to spend on a build. Before a pilot, a large build is a guess with employees attached.
The founder-as-customer trap: you have the problem, so you skip interviews. Sometimes you are in the ICP. Still talk to five people who are not you. You will forgive your own product. They will not. If you cannot find five, you may be building for a club of one.
Mixed signals are normal. Three buyers want a report; two want an integration; one wants a mobile app. That is not a mandate to build all three. It is a mandate to pick the test. Put the others in validate-first or not-in-v1. If you try to please the mix, you will validate nothing and spend as if you validated everything.
Write down disconfirming evidence. A buyer who already solved it with a $30/month tool and is happy is a signal. A buyer who wants you to staff a services team is a signal that you may have a services business, not SaaS. Neither is a moral failure. Both should change what you hire for.
| Validation method | What it can prove | What it cannot prove |
|---|---|---|
| Interviews | Problem, language, budget holder | That they will pay you |
| Landing page | Interest in an offer | Retention or willingness to implement |
| Design partner | Usage of an ugly version | A whole market, if you only have one friend |
| Paid pilot | Money and a success definition | That self-serve SaaS will work later |
A sequence you can start this week
- Write the fail-able sentence and the pass/fail numbers.
- List twenty ICP contacts. Book five conversations.
- Ask the table questions. Request an artifact. Request a paid or signed next step.
- If interest exists, ship a specific landing offer or a one-page PDF. Count replies that include a meeting or a payment, not likes.
- Recruit three design-partner conversations. Aim for one paid pilot in the next two weeks, even if you run it manually.
- Only then cut what should be in an MVP and talk to developers. If you need a document they can estimate from, that is the blueprint, not a PRD (product requirements document — a detailed spec for a later team).
If you cannot complete steps 1–3, you do not have a developer problem. You have an access problem. A fractional CTO (a part-time senior technical leader on a retainer) will not invent your buyers. Neither will I.
If the idea itself is the open question, a 45-minute Idea Validation session ($149) is for deciding whether to proceed and what to test next. It is not a written report, and it cannot manufacture buyer conversations you have not had. Strategy, blueprint, and advisory packages come later, and none of them include building the product.
Book through the consultation page. Fees are non-refundable once paid, except if I cancel and we cannot agree a new date.
Prove a buyer will pay. Then hire. The other order is how you fund a demo.
Questions people ask
How do I validate a SaaS idea before building?
Talk to buyers about how they solve it today, then get a commitment: payment, a letter of intent, or a paid concierge pilot. Opinions are not validation.
Is a landing page enough?
No. A landing page tests interest. Recurring SaaS needs evidence people will pay monthly, not just that they will type an email.
When should I hire developers?
Hire developers after the problem, buyer, and willingness to pay are evidenced, and the MVP list is cut.
How many interviews do I need?
Enough that you hear the same costly problem in the same job. Ten serious conversations beat fifty compliments. Stop when you can predict the answers.
What is a design partner?
A design partner is a real buyer who will use an early version, give you the ugly workflow, and usually pay or formally commit. Not a friend who likes your deck.
Are waitlists validation?
No. They are a weak signal of curiosity. A waitlist plus a paid deposit is stronger. A waitlist alone is not a reason to hire a team.
Can you validate the idea for me in a call?
In 45 minutes we can pressure-test the assumption and the next test. We cannot manufacture buyer conversations you have not had.
Does validation consulting include building a landing page?
No. Packages are strategic guidance. Implementation is separate. Fees are non-refundable once paid except if I cancel and we cannot agree a new date.