Two operators, both with 12 years inside the same field service industry. Both left to start software companies in year 13. One built a company that sold for $85M. The other burned through $1.2M in venture funding on a product that never found traction and shut down 30 months in.
The difference wasn't execution. They had similar work ethics, similar founding teams, similar pitches. The difference was vertical SaaS market selection — specifically, the problem they chose to build around before they wrote a line of code.
Domain expertise is the reason operator founders have a structural advantage in vertical SaaS. But domain expertise is a starting condition, not a market selection filter. Knowing your industry tells you which problems exist. It doesn't tell you which ones are large enough to sustain a software company, which have buyers with real discretionary budget, or which ones are already being solved by a competitor you've overlooked.
Why domain expertise doesn't make the choice for you
Most operators approaching their first company assume the choice is obvious. "I know what's broken. Everyone who does this job knows what's broken." That's true, and it's also a trap. Industries contain dozens of broken workflows. Most of them are not software opportunities.
A workflow can be genuinely painful and still fail as a software market for several reasons. The buyer might not have discretionary budget. The problem might happen infrequently enough that companies are willing to tolerate it. The workflow might require such deep services work alongside the software that the economics never pencil out. Or the problem might be real but the workaround — a spreadsheet, an email thread, a dedicated coordinator role — might be cheap enough that customers see no reason to pay $15K/year to replace it.
Operators who've spent a decade in an industry have deep problem-awareness. The additional work is converting that awareness into a judgment about which specific problem has the buyer, the urgency, and the economics to sustain a venture-scale business.
The four tests that separate opportunities from expensive detours
These aren't a checklist you complete over a weekend. They're conversations you have before you spend anything on development.
The "will they pay" test. Not "do they have this problem" — that question is too easy to answer in the affirmative. Will a specific buyer write a check in year one? Pick a price — a real one, not a placeholder — and put it in front of five potential customers. Watch how they respond. If the reaction is immediate budget objection, the problem isn't a priority. If the reaction is "who do I need to loop in to buy this," you've found something. Most operators skip this test and spend 18 months building before they learn the answer.
The budget owner test. Every B2B SaaS sale eventually involves someone with discretionary authority. Do you know who that person is in your target customer? An operations director who runs the workflow you're fixing might be your champion, but if the CFO controls software spend above $5K and has no context for why this problem matters, your sales cycle will stall every time. Operators usually know the org chart — make the budget owner explicit before you build.
The competitor audit. The wrong question is "does anyone else do this?" The right question is: why hasn't this been built well yet? When a market has no strong software players, there's almost always a reason. Sometimes it's that no one with domain expertise has tried. More often it's that the TAM is too small, the buyer is fragmented and hard to reach, or the workflow requires deep implementation work that makes SaaS unit economics difficult. Your audit should surface that reason — and either explain why you can overcome it or tell you to move on.
The reference customer test. Name three specific companies that would be your first customers if you built this — by company name, with a specific person at each — and confirm you have a relationship with those people. If you can do this, you have a distribution advantage that most early-stage SaaS companies would spend 12 months and $500K trying to manufacture. "Companies like them" is not the same thing. Hypothetical early adopters are not early adopters.
The sizing question operators get wrong
When founders ask "is this market big enough?" they usually mean: what does the TAM number look like in a market research report? That's the wrong question for a vertical SaaS company at pre-seed or seed stage.
Market reports aggregate segments that don't reflect your actual target. A report that says "the field service management software market is $6B" doesn't tell you whether there are enough companies in your specific segment — the 20–200 employee HVAC contractors in the southeastern US, for instance — to build a venture-scale business targeting them.
Build the number up from units instead. How many companies fit your exact target profile? What would they realistically pay annually for software that solves this specific problem? Multiply. A market with 4,000 companies, each of which would pay $15,000 per year for your product, is a $60M ARR opportunity. That's a fundable venture-scale business — even if it never appears as a named category in an analyst report.
The follow-on question is expansion. Can you build from that core market into adjacent segments? Operators often have a clearer view of this than outside analysts because they know how the industry is actually organized — which buyers are adjacent to each other, which problems share budget cycles, which verticals have similar workflows. That adjacency is often the path from a $50M company to a $200M one.
The signal that tells you when you've found it
The signal isn't excitement. Operators are excited about multiple problems simultaneously — that's part of having deep industry knowledge. The signal is specificity.
When you can describe the exact moment in the workflow where things break, name the person whose job it is to fix it when it breaks, quantify what it costs the company each time it happens, and explain why the current workaround fails on a predictable schedule — you've found something worth building around.
The operators who get this right usually describe the same kind of discovery: they've been annoyed by the same specific failure for years, it happens on a repeatable schedule, and every time they mention it to peers in the industry, the response is immediate and visceral. "Yes. We deal with that every quarter." That's your signal.
The operators who get it wrong describe a category of problems rather than a specific failure. "Companies in my space struggle with reporting" is not a problem — it's a symptom. "The month-end close process breaks every time because field technicians submit incomplete job records and accounting has to manually reconcile 200 tickets, usually over a long weekend, before the books can close" is a problem you can build around.
If you've found the specific failure, know the buyer, and can name the first five customers — the next question is whether you have the right co-builder to move quickly. Tell us what you're building. Two paragraphs about the workflow is enough to start.