How to Validate a B2B SaaS Idea Before Writing Code

"Operations teams at mid-market companies" is not a buyer. "The person who reconciles supplier invoices at a 40 to 150 person construction firm" is. The narrower definition does three things at once: it makes outreach writable, it makes answers comparable across conversations, and it makes the workflow small enough to actually understand.

Pick one workflow inside that role, not the role's whole job. A workflow has a trigger, a sequence of steps, and a moment where it is done. If you cannot describe the trigger and the finish line, you are looking at an area rather than a workflow, and you will end up building something broad and shallow.

Founders resist narrowing because it appears to shrink the market. It does not shrink the market, it shrinks the beachhead. You can widen later from a position where something works.

The moment you describe your solution, the conversation changes character. Your contact switches from reporting their experience to reacting to your product, usually kindly. Keep the idea out of the first twenty minutes entirely.

• Walk me through the last time this happened. What triggered it and what did you do first.
• What did you do when it went wrong. Who else got involved.
• How long did it take, and what did it delay.
• What have you already tried to fix it, and why did that stop.
• If nothing changes, what happens over the next six months.

Notice that none of these are hypothetical. Y Combinator's essential startup advice is blunt about this: talk to users, and pay attention to what they do rather than what they predict. Past-tense questions are how you get behavior instead of forecasts.

Ask for a screen share where possible. Seeing the actual spreadsheet, the actual inbox, and the actual paste-between-two-systems step tells you more than an hour of description. YC's note on user observation covers the mechanics well.

In B2B, the incumbent is almost never a competing product. It is a spreadsheet, a recurring meeting, a person who just knows, or a partly abandoned internal tool. Document it step by step, including who touches it and how long each step takes.

Two things fall out of this map. First, a credible sense of what the pain costs, in hours and in consequences, which is the basis of any pricing conversation. Second, the insertion point: the single step where a tool could replace something without requiring the whole process to change. Products that need the entire workflow rebuilt around them lose to spreadsheets more often than they should.

This is where B2B ideas quietly die. The person with the pain frequently cannot spend. Ask directly and specifically: what was the last tool your team bought, who approved it, how much could you approve yourself, and what does anything above that require.

You are looking for three facts. Whether a budget exists for this category, who signs, and what the approval process involves in practice rather than on the org chart. A one-person decision at a few hundred a month is a completely different company to build than a six-signature purchase at twenty thousand a year.

If the answer is that nobody owns this budget, that is not a dead end. It means your first sale is a story about which existing budget this comes out of, and you should test whether that story holds before building.

Deliver the outcome by hand for two or three companies. You in a spreadsheet, on email, doing the work a product would eventually do. It feels unscalable because it is, and that is not the point. Strategyzer's experiment library treats this as a core experiment type for the same reason: it produces evidence about the outcome instead of the interface.

Charge something, even a small amount. A paid manual service tells you whether the outcome has value. A free one tells you whether people accept free help, which they always do. Keep the scope written down and the delivery dates explicit.

Track what you actually spend time on. The gap between what you assumed the work was and what it turns out to be is your product specification, and it is usually narrower and stranger than the roadmap you would have written from a whiteboard.

The paid pilot is the strongest evidence available before a product exists. Short, scoped, with an agreed success measure and an invoice. A Stripe payment link or a simple invoice is all the infrastructure you need.

Its real value is procedural. To pay you, a champion has to raise this internally, defend it, and get it through whatever approval process exists. That is the exact sequence that will decide your sales cycle later, and you get to observe it while it is cheap to learn from.

• A defined scope with a start and end date.
• A success measure both sides agree on in advance.
• A named champion and a named approver.
• A price that is small but real, and refund terms in writing.
• An explicit statement of what exists today and what does not.

Write down, before you start, what result would make you continue and what result would make you stop. Something like: eight conversations booked from fifty emails, five workarounds documented, two budget owners identified, and one paid pilot agreed. The numbers matter less than deciding them in advance.

Without a written threshold, every outcome becomes encouraging. Two polite calls and a maybe turn into momentum. Strategyzer's test card exists mainly to force this discipline, and it works.

Seven days is enough to find out whether this idea is worth another month. It is not enough to prove a business, and any process that claims otherwise is selling certainty it does not have. Treat the week as a way to replace assumptions with observations quickly.

Two things routinely break this schedule, and both are normal. Calls get pushed, so send more outreach than you think you need on day one. And a good conversation on day three often changes the buyer definition, which means restarting the week with a better target. That is progress, not a delay.

At the end of the week, sort what you learned into observed, told, and assumed, then pick one of three moves.

1. 01Continue with the same buyer

   You hit your thresholds, the workaround is real, and at least one budget owner engaged. Next step is a paid pilot or a second concierge customer.

2. 02Change the buyer or the workflow

   The pain was real but sat with a different role, or the workflow was wider than you thought. Rerun the week with the corrected target. This is the most common outcome and it is a good one.

3. 03Stop

   Nobody replied, nobody had a workaround, and no budget exists. Write down why in two sentences and move on, so the same idea does not return unexamined in three months.

For the broader evaluation frame, see how to evaluate a startup idea and Build, Explore, or Skip. If willingness to pay is the part you are least sure about, seven tests that produce real evidence goes deeper on that specifically.