When someone says they'd buy, how do you know they will pay?

Buffer solved one annoying problem in social media posting: you wanted a queue of content going out on schedule, instead of setting each post up by hand.

According to the founder's own account, he started with two plain web pages describing the product, plus a form for interested people to leave their email address. Next came a page asking visitors to choose a price plan, so he could watch which option people clicked and whether anyone kept going. Only after someone actually selected a paid plan did he build a working version, using evenings and weekends over seven weeks. Within four days of launch, the first customer paid.

The worth of that sequence is that every extra bit of work answered a sharper question. The description pages told him whether anyone cared at all. The price page showed how people reacted to a real number. The working product made buying and using happen for real. Before committing to the next chunk of effort, you can run the same check: what do I most need to know right now, and what behavior would show me?

Developers are good at describing the feature they want to build. Customers tend to know more about the last time it went wrong.

For a scheduling tool, you could ask when someone last had a run of posts to publish, how they managed it, where they got stuck, and whether they'd tried other tools for it. Questions like that surface how often the pain happens, what people currently do about it, and what it costs them.

Then pick one improvement, narrow enough that your prototype has a clear job and your demo has something specific to show.

A trial that produces useful feedback should let a customer see what the product does, what it costs, and how they get the result. For physical goods, show a sample. Selling software? Show a usable version. Selling a service? Start from one clearly scoped deliverable.

If you take reservations, explain what happens after someone signs up. If you take a deposit, write down what gets delivered, by when, and what cancellation means. People behave differently once they know exactly what they're agreeing to, and that makes their behavior easier to read.

Keep notes in this order:

With reservations, payments, and usage recorded separately, you can see exactly where a person stopped, and then ask about that step instead of guessing.

Track where each prospect came from, how many saw a clear price, how many paid, who refunded, and what usage said afterward. That lets you compare conversion within the same round, and the accompanying feedback helps explain why customers continue or drop off.

Patterns point at the fix. If people keep asking what the product is for during every demo, your explanation is the weak link. If they say they want a specific outcome but freeze at the price or the timeline, press on what they're weighing. If paying customers all hit the same snag after checkout, the product needs work, not the pitch.

After landing that first paying customer, Buffer shifted its energy toward marketing and learning about users. Early orders are valuable because they hand you things to follow up on: real people, real reasons they bought, real costs of getting the sale. Chase those leads and the next round of building has a target attached to it.

If you need to sharpen the buying reason first, see How to find customers who will pay when you're not the industry leader; once you have orders, move on to Doing the numbers after you've made a sale. The underlying concepts are covered in Willingness to pay and demand validation. To decide the next investment, read whether to continue, change, or stop a half-finished project. Follow the complete route in from finding customers to earning money.