
Rocketech editorial update — .
Before building a B2B SaaS product, use a financial model to decide whether the opportunity is worth testing, not to make an untested idea look investable. Start with a reachable buyer group, a painful workflow, a credible willingness-to-pay hypothesis and a spending limit. The first output should be a go, revise or stop decision.
Model the decision before the spreadsheet
Name the buyer, user and budget approver. Record the existing workaround, frequency of the problem, cost of leaving it unresolved and constraints on adopting a replacement. Y Combinator’s guide to talking to users recommends learning from actual behavior and problems; a positive reaction to your pitch is weaker evidence than a concrete account of what the buyer already does.
Keep an evidence register: assumption, source, date, confidence limitation, owner and next test. Mark unknowns as unknown. A founder’s guess should not look identical to a paid pilot or a signed agreement, and a pilot does not automatically predict a repeatable sales process.
Estimate reachable demand from the bottom up
List the accounts in a narrow segment that your actual channel can reach during the test period. Then model contact capacity, qualified conversations, offers, paid commitments and the time between these stages. Avoid taking a small arbitrary share of a large global market and calling it a forecast.
SBA market research guidance provides the research questions: demand, size, location, saturation and alternatives. Use these to investigate the segment, then document your own channel access and buying evidence. Public market size is context; it does not establish the number of customers you can win.
| Decision area | Evidence or input | Action before commitment |
|---|---|---|
| Problem | Recent examples of the workflow and its cost to the buyer | Stop or revise if the problem is infrequent or already solved adequately. |
| Willingness to pay | An explicit offer, price hypothesis, buyer response and procurement path | Test a paid pilot where appropriate; do not equate compliments with purchase intent. |
| Reachable demand | Named account segment and a channel you can actually use | Cap the experiment and measure qualified conversations. |
| Delivery economics | Minimum scope, onboarding effort, support and third-party costs | Compare build, buy and manual delivery before committing. |
| Cash exposure | Affordable loss, payment timing and available founder capacity | Choose the decision date and stop condition before development. |
Test price and adoption without building the whole product
Show an honest prototype or offer a clearly scoped manual service or pilot when it can test the core value. Explain what exists and what does not. Ask who approves purchase, what security review is needed and what switching work the customer must do. Willingness to pay includes timing and conditions, not just a preferred price.
Compare the cost of delivering that pilot with the cash you can collect. Include founder time, onboarding, integration and customer support even if no external invoice arrives. Test a slower-sales scenario and a higher-support scenario. These are nonprobabilistic alternatives, not confidence levels or market validation.
Make a bounded investment decision
- Go: release only the next learning budget when the evidence meets your written gate.
- Revise: narrow the segment, change the offer or test a different channel when one assumption fails.
- Stop: do not finance a full build when buyer access, willingness to pay or affordable delivery remains unsupported.
Once you have contracts, spending and collection history, use the B2B SaaS operating-model guide to maintain monthly revenue, cash and runway. This pre-build guide is about whether to invest next, not how to operate an established subscription forecast.
Turn your assumptions into a project brief
When buyer evidence supports the next experiment, discuss the smallest useful build with our startup development team. Read the Guestroom case to frame delivery questions, not to substitute another product’s results for your own demand research. Explore software development for startups and the Guestroom case study.
Discuss a bounded pre-build market experiment
Start with an AI-assisted project brief covering scope, budget, market assumptions and risks. Review its hypotheses before making a commitment.