Demand Posts: Validate Software Ideas Before You Finish Building

Most validation methods start with the builder's idea and go looking for people who agree with it. Surveys, landing pages and interviews all begin with "here is what I am thinking of building". The answers are shaped by the question.

A demand post works the other way round. A business writes, unprompted, "I am looking for software that does this", in its own words, with its own constraints. Nobody pitched them first. For a builder, that is some of the cleanest evidence available that a problem is real, and it arrives before you have written the code for it.

This post covers how to read demand posts properly, how to turn a cluster of them into a validation test, and how to approach a business without wasting the signal.

Why an unprompted request is different

When you interview someone about a problem you have described, they are being helpful. They will usually agree it sounds annoying. That politeness is exactly what Rob Fitzpatrick's book "The Mom Test" warns about: people are kind about your idea, and kindness is not evidence.

A demand post removes you from the start of the conversation. The business chose the words, the category and the priority. That gives you three things interviews struggle to give:

• The problem in the customer's language. "I need something that tells drivers where to be without me ringing them" is a better headline than anything you would write.
• A stated constraint. Team size, budget range and region come with the request, rather than being teased out.
• Evidence of intent. Someone took the time to post. That is a small cost, but it is more than clicking a survey link.

It is still only a request. A demand post tells you a problem exists and someone wants it solved; it does not tell you they will pay you. Treat it as the first rung of evidence, not the last.

Anatomy of a demand post, and what each part tells you

On LetsBeta's demand board, a business fills in a short form. Each field answers a different builder question:

| Field | What the business writes | What it tells a builder | |---|---|---| | One-line need | "Chauffeur booking software" | The words to use in your listing and search | | What it has to do | "Five drivers, online bookings, card payments and driver allocation" | Your must-have scope for version one | | Category | Transfer and chauffeur booking | Where this sits against other demand | | Region (optional) | Queensland, Australia | Tax, compliance and language needs | | Team size | A small team | Seats, permissions and price shape | | Monthly budget | A range, or "not sure yet" | Whether your intended price is in the room | | Contact preference | Off unless the business ticks it | Whether an introduction is possible at all |

The "what it has to do" line is the most useful. It is effectively a customer-written spec for a minimum viable product. If five businesses in one category list overlapping must-haves, the overlap is your first release.

Posts are anonymous by default: without the contact box ticked, a post shows as a business in its region, with no name. That protects the business and keeps the signal honest.

A worked example: reading a cluster

Here is a hypothetical cluster of five posts in one category, the kind of pattern worth looking for. These are illustrations, not real posts.

1. "Booking and reminders for a mobile dog-grooming van. Clients book online, I need travel time between jobs."
2. "Scheduling for two groomers. Online bookings and deposits, texts the day before."
3. "Something to replace my paper diary for grooming appointments. Must handle repeat bookings every six weeks."
4. "Pet salon software. Owner and pet records, vaccination dates, online booking."
5. "Mobile groomer, want customers to see available slots in their suburb only."

Read across them and three things stand out:

• Online booking appears in four of the five. That is table stakes, not a differentiator.
• Two mention travel or suburbs. Mobile groomers have a routing problem a general salon tool will not solve. That is a possible wedge.
• Repeat bookings and reminders appear repeatedly. The rebooking cycle is where the time goes.

From this, a first version might be: online booking restricted by suburb, repeat appointments, and reminder texts, for solo and two-person mobile groomers. That is a much narrower product than "pet salon software", and a much more winnable one. It is the same logic as Geoffrey Moore's beachhead: pick the segment you can serve completely, then expand.

From signal to test in four steps

Demand posts tell you where to look. The test is whether businesses will use the thing you build.

1. Write the smallest version that covers the overlapping must-haves. Not everything in every post: only what appears again and again.
2. Describe it in the posters' language. Reuse their phrases in your listing title, tagline and first steps.
3. List it as a beta program with a clear price. Show the full price, an early-adopter price and how long the discount lasts. A budget band from the posts helps you check you are in range.
4. Measure what the trial tells you. Applications, completed first steps, mid-trial reports, and the end-of-trial answer to "would you pay, and what is fair?".

If businesses in the category apply, use it and say they would pay, the demand was real. If the category was busy with posts but nobody applies, the problem may be real but your version of the solution is not what they had in mind, and the end-of-trial reports from anyone who did try it will usually say why.

Asking for an introduction, properly

Some businesses tick "builders may contact me". On LetsBeta, builders on Builder Max can ask for an introduction to those businesses, and the business decides whether to accept. No contact details are exchanged either way; the conversation stays on the platform.

Because the business chooses, the first message matters. A useful structure:

• One line on what you built, in their terms: "We built booking software for mobile groomers."
• One line connecting it to their post: "You mentioned customers should only see slots in their suburb. That is how ours works."
• One clear next step: "There is a free trial open now if you would like to try it on next week's bookings."

Keep it short, and never send the same message to every post. A business that feels mass-mailed will say no, and it should.

What demand posts cannot tell you

• How many businesses have the problem in total. A board shows who posted, not the whole market.
• Whether they will switch. People often want something better and still stay with what they have.
• Whether your price works. A budget band is a starting point, not a commitment.

Builder Max includes demand insights: what businesses are asking for, broken down by category, budget, team size and region, and how many are happy to be contacted. That is useful for deciding where to build next, as long as you read the counts as interest rather than customers.

For businesses posting a need

If you run a business and cannot find the right tool, a good post helps builders help you. Be specific about the job ("allocate five drivers to airport transfers"), not the product category alone. Include the one thing your current tool gets wrong. Leave the contact box unticked if you only want to signal the need; tick it if you are happy to hear from builders.

Related reading: Beachhead Market: How to Pick the First Segment You Can Actually Win and LetsBeta vs BetaList.

Builders: see what businesses want, and when your first version is ready, list your beta.