You can validate a micro SaaS idea without followers, an email list, or a finished app. Start by finding people who already handle the task you want to improve. Learn what happened the last time they did it, offer a small manual solution, and observe whether they commit time, data, or money.
The aim is to earn enough evidence for your next investment. A conversation can reveal a problem. A paid pilot can test a specific offer. Repeated use can help you judge whether a subscription makes sense. Each answers a different question.
This guide walks through that process before you commit to building software. The reporting workflow below is a hypothetical example, used to make the steps concrete.
Define a problem you can investigate
Write one sentence naming a buyer, a recurring task, and a consequence when it goes wrong.
For example: "Owners of small content agencies spend time combining client campaign exports into weekly reports, and late reports delay client reviews."
That sentence contains assumptions. You still need to discover whether owners do the work, how often reports are due, and whether delays matter enough to justify spending money.
Keep a short assumption list:
Choose one segment for the first round. Combining agencies, freelancers, and internal marketing teams can hide differences in budgets and workflows. If you change segments later, keep their evidence separate.
Define a stopping point too. You might allow two weeks of research and a small pilot before deciding whether more work is justified. This is a suggested limit for your effort, not a promise that every idea can be validated in two weeks.
Find problem evidence before asking for opinions
Search for descriptions of the task rather than your proposed product name. For the reporting example, try searches such as:
Read public support discussions, specialist blogs, software documentation, and job descriptions. Look for a recognizable workflow: someone exports files, fixes inconsistent columns, checks totals, and sends a report.
Record the source, date, role, task, workaround, and consequence. Keep your interpretation separate from what the source actually says. A complaint about an export format does not establish demand for a new reporting subscription.
Check existing software for the same job. Read its own feature and pricing pages to understand what buyers can already purchase. Your opportunity might involve a neglected input format, a simpler workflow, or a segment with different needs. Existing options also give interviewees a useful comparison.
Search evidence helps you form questions. It cannot tell you whether reachable buyers will trust you or pay your proposed price.
Recruit prospective buyers without building a following
Make a small list from public business websites, professional profiles, and introductions. Choose contacts because their work suggests a fit. For each person, note the public detail that connects them to the task.
An agency website offering weekly campaign reviews is a plausible lead for the reporting example. A generic business email with no evidence of relevant work is much less informative.
Start with a manageable batch, such as ten carefully selected contacts. The number is a planning choice, not a response benchmark. Record messages sent, replies, qualified conversations, and declines so you can distinguish a recruitment problem from weak demand.
Use an honest research invitation
Here is sample wording to adapt only when the details are true:
Hi, your agency website mentions weekly campaign reporting. I'm researching how small agencies turn campaign exports into client reports before deciding whether to build a tool. Could I ask how you handled your most recent report? A short email reply is welcome, or we could arrange a brief call.
Avoid pretending you are conducting independent research if you are exploring a commercial product. Keep the first request easy to answer, and stop contacting anyone who declines.
If nobody replies, examine the contact choice and request before discarding the idea. Try a clearer question or ask an existing contact for an introduction. Silence alone cannot distinguish an irrelevant message, a busy recipient, and a problem they do not care about.
If you repeatedly cannot reach suitable buyers, record that as a constraint. A product whose customers you cannot access may be difficult for you to pursue, even when the problem exists.
Interview people about their most recent attempt
Ask about an actual event before showing a solution. Keep the conversation anchored to what they did and what followed.
Use these questions in order:
Ask for a walkthrough using a redacted example if they are comfortable sharing one. Do not request credentials or private client information. If they estimate time or cost, label it as their estimate in your notes.
Separate politeness from useful evidence
"That sounds useful" leaves many questions unanswered. A recent example, an existing workaround, and a consequence give you something to investigate.
Listen when someone says their current spreadsheet works well. Ask what makes it sufficient. If the task is infrequent or easily delegated, a subscription might be difficult to justify.
Close by asking whether you may return with a specific offer. Permission to follow up is a next step, but it does not establish buying intent.
After each conversation, write a brief summary before talking to the next person. Capture the recent incident, current process, consequence, purchasing authority, and unresolved question. Avoid replacing the person's words with a feature wishlist.
Turn the repeated problem into a manual offer
When separate buyers describe a similar difficulty, test whether you can deliver an outcome they value. Start with the smallest version you can fulfill manually.
For the hypothetical reporting tool, the offer might be:
I will combine two agreed campaign exports into one client report for your next weekly review. You provide redacted files by Tuesday, and I deliver the report by Thursday. The pilot costs $40 for one report and includes one correction round. I will prepare it manually. There is no automatic renewal.
The scope, price, and dates are illustrative. Choose terms that fit your actual capacity and the buyer's workflow. Explain what you will deliver, what they must provide, what happens if you cannot deliver, and when payment is due. Agree on how supplied files will be handled and deleted.
Ask a direct question: "Would you like to book this pilot for your next report?"
Record the next action. Did they send the agreed files, arrange approval, accept the scope, or pay? If they hesitate, ask what prevents the decision. Budget, timing, missing trust, and an unsuitable output call for different responses.
A free pilot can test usefulness, but leaves willingness to pay unresolved. A promise to buy later also remains uncertain until the buyer acts. Keep those distinctions visible.
Use a simple page when the offer needs explaining
You may need a page to show a sample output or let someone review the offer with a colleague. Put the intended buyer, outcome, example result, pilot price, limitations, and next step together.
State plainly that the work is currently manual or that the software is still proposed. Do not show a working checkout for a product you cannot supply as described.
Invite the people you interviewed to review that page. Ask whether the offer matches their task, then give them a concrete action such as requesting the paid pilot. Record which qualified contacts saw the offer and what they did next.
Email signups can help you reconnect, but they do not answer the payment question. A quiet page that nobody relevant visits tells you little about demand. You do not need a broad launch to test this offer.
Once a working product exists, you can submit your product to RadarMakers as a separate way to showcase it. Keep that later activity distinct from evidence collected from prospective buyers before building.
Check whether the outcome could support a subscription
Deliver the agreed pilot and observe what the buyer does with the result. Ask them to compare it with their normal process. Did they use it in the intended review? What still needed correction? What work remained on their side?
Record your delivery time, direct costs, and every manual exception. A useful service may require custom judgment that would be expensive to automate. Identify the repeated steps and the customer differences before deciding what software should do.
At the next natural reporting cycle, offer another delivery at clearly stated terms. Ask whether the task recurs often enough to justify an ongoing arrangement. An accepted second delivery provides evidence about recurrence; a single purchase could reflect a temporary deadline.
Compare the proposed recurring price with likely operating costs and your available support time. You do not need precise forecasts yet, but you should know which uncertainties could make the idea unworkable. Test a difficult file format or costly dependency before promising automation.
Make a build, revise, or stop decision
Review your notes against criteria you chose before the pilot. For a modest first experiment, you might seek several independent accounts of the same recent problem, two accepted paid pilots, and at least one request for another delivery. These are example decision criteria, not universal validation thresholds or proof of a market.
Choose criteria that reflect the cost of your next step. A weekend prototype needs less commitment than months of development involving complex integrations.
Build a narrow version
Proceed when buyers describe a recurring problem, accept a concrete offer, use the result, and show a reason to return. Build the repeated step you have observed. Keep unresolved requirements outside the first version unless they prevent delivery.
Write down remaining risks. Paid manual work does not establish that customers will adopt software, complete setup independently, or stay subscribed. The next version should test those assumptions.
Revise one assumption
If the problem is clear but the offer stalls, choose one change based on the objection. You might narrow the buyer segment, simplify the required input, or change the deliverable.
Record the changed assumption and test it with suitable buyers. Changing the segment, price, and promise together makes the result harder to interpret.
Stop or set the idea aside
Pause when suitable buyers consistently describe little consequence, prefer their current process, or decline a clearly explained offer. Also pause if you cannot deliver economically or reach the people who control spending.
Save the evidence and state what would make the idea worth reopening. That could be access to a specific buyer group or a change that removes an expensive delivery step.
Your next action can be small: choose one buyer group, find evidence of its task, and ask someone about their most recent attempt. Let their behavior determine the next investment. When that work leads to a usable product, submit it to RadarMakers with a description grounded in what you can actually deliver.
Sign in to join the discussion
Log inProduct discoveries and maker stories in your inbox. Unsubscribe anytime.