ServiceTitan, Jobber, and Housecall Pro dominate the HVAC/plumbing software market with thousands of customers each. They did not win because their code is better—a competent developer could replicate most of their features in a few days using modern AI tools. They won because their founders or early sales teams spent years inside HVAC businesses before writing a single line of code. They know what dispatch software should do because they lived inside the problem. When a shop owner asks “Will this work with my existing Quickbooks integration?”—they do not have to learn the answer. They already know.
This is the coordination trap that has quietly reshaped vertical SaaS in the age of commoditized code execution. The economic condition is straightforward: as the cost of building software approaches zero, the value of domain credibility approaches infinity. And for developers without that credibility, there is no accelerator, no platform, and no mainstream playbook that tells you how to acquire it—only the knowledge that you must, and that you are already behind.
The real constraint is not engineering. It is the 6–12 months of embedded learning that cannot be compressed, regardless of how many GPU tokens you have access to.
Why This Is Happening
Start with what has changed. Ten years ago, if you were an HVAC contractor frustrated with your dispatch software, you had three options: buy expensive, inflexible enterprise software; accept what the market offered; or wait. The barrier to entry for a competitor was high enough that domain expertise alone was not decisive—you also needed capital, senior engineers, and marketing reach. Your knowledge of HVAC was valuable, but only if you could also hire people to build and sell.
That barrier has collapsed. An average developer can now build 80% of Jobber’s feature set in a month. AI-assisted coding has made the engineering constraint so permeable that “can we build this?” stopped being the question. The question became “should we?”—and for most developers without domain expertise, the answer is increasingly no.
This is a coordination problem, not a market problem. The market is real. Small business software is fragmented, underserved, and often appallingly bad. There are genuine unmet needs across hundreds of vertical segments—locksmiths, dental practices, construction crews, landscapers, carpet cleaners. But the structure of knowledge, credibility, and distribution has not caught up with the fact that code is now free to produce.
Consider the established playbook for vertical SaaS, as documented by SaaStr and BVP Capital (Bessemer Venture Partners). The pattern is consistent: find a founder with 8–15 years of domain expertise. That founder has relationships in the industry, understands the cost structure of the business, knows where the software is broken, and—critically—has the credibility to walk into a shop and be taken seriously from the first word. Every case study in the BVP playbook “Ten Lessons from a Decade of Vertical Software Investing” features a founder who already had deep credibility. The VC firms backing vertical SaaS explicitly select for domain expertise as a founder characteristic. As one SaaStr sales consultant put it: “Most complex vertical SaaS start-ups haven’t made their first 1–2 sales reps successful unless they have domain expertise. Not all, but most.”
The indie developer with no HVAC background does not fit this template. They cannot hire a sales team. They cannot wait three years for a VC round. And critically, they have no way to credibly claim competence to a locked market.
A secondary dynamic has reinforced this trap: the indie developer community has become too successful at building products for other developers. As discussions on Hacker News and Reddit’s r/indiehackers community have repeatedly surfaced, the majority of indie-backed SaaS products end up serving other indie developers—people interested in “building in public,” analytics tools for SaaS founders, workflow automation for remote workers. It is a tightly coupled ecosystem where distribution is frictionless because the audience shares the builder’s reference frame. But that same frictionlessness has made it extremely hard for developers to break out of this circle and sell to businesses with no interest in following their Twitter threads. A developer who wants to build for HVAC shops has to solve a completely different problem: how to reach people who do not read Product Hunt, who do not know what GitHub is, and who will not trust someone without verifiable experience in their industry.
The playbooks, the community infrastructure, and the business models of indie SaaS have all optimized for developer-to-developer sales. That optimization has created a moat—but not in the direction that matters for most small businesses.
What Developers Are Actually Doing
A subset of developers have recognized this trap and are working around it. Their approaches reveal where the actual constraints live.
The most visible pattern is the “domain credential acquisition through observation” strategy. Developers are spending 4–6 months working inside a target vertical—sometimes as employees or contractors, sometimes as volunteer/discount adopters—before building any software. They are deliberately trading execution speed for credibility. This is a rational response to a verification problem: because there is no institutional way to prove competence in a domain, developers are accumulating lived experience as a substitute.
Some developers are partnering with domain experts. A developer with strong execution skills partners with a former HVAC technician or a retired shop owner who has credibility but no technical depth. The domain expert handles discovery and early sales; the developer handles build and iteration. This creates a compressed version of the vertical SaaS founder profile: credibility (from the domain expert) plus execution (from the developer). The economic disadvantage is obvious—the developer is giving up equity and control. The advantage is equally obvious: they can skip the 6–12 month solo learning curve.
Others are doubling down on underserved sub-segments where credibility barriers are fractionally lower. Instead of building for “HVAC contractors,” they build for “HVAC contractors in non-urban markets under 50 employees who currently use spreadsheets.” The credibility question does not disappear, but the total addressable market gets smaller, and so the time required to reach “critical mass of customers” shrinks. This is a purely defensive move—you are not solving the credibility problem, you are just making it tolerable by reducing the scale you need to operate at.
The absence of infrastructure for discovering these opportunities is acute. If you are a developer who wants to enter vertical SaaS but do not have a domain credential, there is no standard place to go. There is no registry of “underserved verticals by friction-to-entry.” There is no community platform that matches developers to domain experts seeking technical co-founders. There is no marketplace where domain specialists can post unsolved software problems and developers can bid to learn and build. What exists is fragmented: Reddit discussions, founder communities like Indie Hackers or Microconf, occasional Twitter threads from people sharing their vertical SaaS experiments. None of this constitutes a systematic way to discover and evaluate opportunities. It is folk knowledge, traded peer-to-peer.
The result is high variance and high friction. The developers who break through are usually those with geographic proximity to a domain expert, personal relationships inside an industry, or enough capital and confidence to spend 6 months learning before building. The developers who do not have those advantages tend to stay inside the developer-to-developer ecosystem, where distribution and credibility work for free.
The Build Opportunity
The infrastructure gap is specific and addressable, even if no single platform can eliminate the domain credibility bottleneck entirely.
What would actually help: a structured system for developers to discover which vertical markets are underserved, access credible guides who already work in those verticals, and build credibility through documented work rather than assumed expertise. This is not a SaaS product in the traditional sense. It is a three-layer infrastructure problem.
Layer 1: Discovery and Opportunity Vetting. A transparent registry of vertical software opportunities, built from multiple signals: job posting frequency for that vertical (signals market size), average software spend per business, stated pain points from practitioners in Reddit/Twitter/forums, and rough estimates of existing competitor market share. The registry should be queryable by developer: “Show me underserved verticals with <$1000/month average software spend, <5 established competitors, and >1000 addressable businesses in the US.” This is not complicated data to gather—it lives in LinkedIn, Glassdoor, Reddit, job boards, and SurveyMonkey research. What is missing is the aggregation and structure. An open-source tool that periodically scraped this data and surfaced patterns would immediately clarify where the real white-space opportunities are (spoiler: many small business operators are paying $300+/month for spreadsheet-replacements because nothing better exists).
Layer 2: Credibility-Building Infrastructure. A platform or community that facilitates structured learning partnerships between developers and domain practitioners. Not equity partnerships (though those can happen)—simple apprenticeships. A developer commits to 2–3 hours per week for 4 months, during which they shadow a business operator, do work inside that business context, and document what they learn. The operator benefits from a cheap technical consultant; the developer builds credible experience. At the end, the developer can legitimately say “I have spent 400 hours inside X-type businesses. I understand the problems.” This is not a magic credential, but it is dramatically better than nothing. The infrastructure would just need to be a matching system, a template for how to structure the collaboration, and a way for developers to publicly document what they learned. Communities like Indie Hackers or StartupCommunity could integrate this; GitHub could host documentation; open-source mentorship platforms already exist and could be adapted.
Layer 3: Credibility Signaling. Once a developer has embedded learning, they need a way to credibly claim it to prospects. This is partly about platforms (a registry of developers with verified experience in specific domains, searchable by business owners), but mostly about standards. What does it mean to have “credibility” in a vertical? If SaaStr and BVP say domain founders need 8–15 years of lived experience, then a developer with 6 months of structured apprenticeship cannot claim equivalence. But they can claim something narrower and more honest: “I have spent 400 documented hours in this business type and have consulted on 12 problems.” That specificity is more credible than vagueness, and it is a foothold.
The technical starting point is open-source and modular. A GitHub repository that catalogs vertical SaaS opportunities with the discovery signals mentioned above could be built by a solo developer in a few weeks—scraping LinkedIn job data, Crunchbase competitor data, and community sentiment from Reddit using existing APIs. An open-source matching and documentation system for apprenticeships could be built by adapting existing platforms like Open Source Mentoring or even repurposing project management tools with a credential layer. The hard part is not the technology. It is the standardization—getting the community to agree on what signals “I have credible experience in this vertical” and building the infrastructure to make that signal sticky.
The immediate practical build: a search tool that indexes vertical SaaS opportunities, surfaces underserved segments, and shows the “credibility cost” of entering each one. A developer queries “least-defended software markets in home services,” and the tool returns sorted results with information about existing competitors, market size, and—critically—average years of experience founders in that space had before building. This creates a transparent tradeoff: “If I enter the HVAC software market, I am competing against founders with 12+ years of domain experience. If I enter the carpet-cleaning software market, I am competing against founders with 3–5 years. Here is the difference in implementation complexity and customer willingness to pay.” That information alone would shift developer decision-making and create more realistic entry strategies.