How to Sell Before Building an MVP
Sell the result you can deliver before you build the software#
“How do you sell before building?” A recent founder discussion landed on the hard part fast. Customers will tell you the truth, but only after you ask them to commit to something specific. Interest is not that commitment. A customer saying, “I would use that,” is useful. It tells you the problem is familiar. It does not tell you they will pay to solve it now. The useful test is simpler and harder. Ask one target customer to pay for a narrow result you can deliver manually.
Get customers before building, not more polite validation#
A real problem can create a dangerous kind of confidence. People recognise it. They agree it is painful. They may even say there is heavy demand. Then the founder starts planning the MVP. This is where many first-time B2B founders get stuck. They have evidence that the problem exists, but no evidence that their version of solving it is worth buying. More interviews will not always close that gap.
At some point, the question has to change from, “Would this be useful?” to, “Will you pay for this result by this date?” That question feels uncomfortable because it can produce a no. It can also save you months of building the wrong thing. This is why validation does not mean you should build immediately.
A paid pilot before an MVP has a smaller promise#
Pre-selling a startup idea does not mean acting like your product already works. It means selling something you can actually deliver. A paid pilot has four parts:
- One named outcome.
- A clear timeframe.
- A manual way you will do the work.
- Clear limits on what is not included.
Say you want to build software that helps a sales team find accounts that match their best customers. Do not sell “an AI prospecting platform.” Sell a two-week pilot that delivers a reviewed list of 50 accounts matching agreed criteria, with a short explanation of why each one fits. You might use a spreadsheet. You might do research yourself. You might use existing tools behind the scenes. That is fine. The customer is not buying imaginary software. They are buying progress on a problem that matters to them.
Your product can come later.
A concierge MVP lets you learn what deserves code#
A concierge MVP sounds more complicated than it is. You do the work manually before you automate it. This is not a trick. It is a way to avoid building features around guesses. Manual delivery shows you what the customer actually needs to reach the result. It also shows you where the work repeats. Some parts will take too long. Some parts will not matter. Some parts will be the reason the customer pays. That is the useful learning. Do not automate the first step just because it is repetitive.
Automate the part that keeps appearing in paid work and slows down a result the customer values. Your first paid pilot is not proof that you need to build everything. It is evidence about what is worth building first.
Pre-sell a startup idea without misleading the buyer#
The line is simple. Do not promise software you have not built. If a dashboard does not exist, do not say the customer will get dashboard access. If an integration is not ready, do not imply it will run in their systems. Tell them what will happen instead. “I will personally deliver this analysis each Friday for four weeks.” “I will recruit and interview five users in this role, then bring you the patterns.”
“I will review your support tickets, identify the repeated issue, and give you a working process for handling it.” Specific language protects both of you. The buyer knows what they are paying for. You know what you have agreed to deliver. Vague promises do the opposite. They turn a small test into an obligation to build a full product for one customer.
Check whether your paid pilot is real#
Before you send the proposal, answer four questions. Can the customer describe the result they are buying? Can you deliver that result without writing code? Can both of you point to the end date? Have you written down what is not included? If any answer is no, the promise is still too broad. Make it smaller. A narrow paid pilot may feel less impressive than a grand product vision. It is also far more likely to get an honest yes or no.
Your first customer does not need your software to exist. They need a clear promise you can personally keep.
If you have found a real problem but need to turn it into a focused first commitment, Acrein Lab can help you shape a pilot that teaches you what to build, without asking a customer to buy something that is not there yet.