The conventional wisdom in software says build horizontal — one tool for every industry scales faster and costs less to acquire customers. That logic holds in consolidated markets with established buying patterns. In fragmented markets, it produces software that serves no one particularly well.
Fragmentation in a market does not simply mean many competitors. It means many bad competitors. It means markets where the dominant software vendor was built fifteen years ago by people who read about the industry rather than worked in it. It means markets where operators are running their businesses on a combination of spreadsheets, paper records, and workarounds so deeply embedded that the operators themselves have forgotten they are workarounds. It means industries where the software problem has been technically solved but operationally ignored — where the tools that exist technically function but practically fail the people who use them every day.
The failure mode of horizontal tools
Take a pool service operator. They have 150 customers, two technicians, a chemical supplier, and state pesticide application compliance requirements. They need route optimization that accounts for pool size and chemical history, not just geographic proximity. They need water chemistry logging that persists across visits and alerts them when a pool is trending toward a problem. They need to send automated service reports to homeowners after every visit because that communication is how they retain customers who never see the work done. They need pesticide application records in the exact format their state regulator requires.
Generic field service software gives them scheduling and invoicing. It does not give them chemistry logging. It does not give them compliance records. It does not give them the automated homeowner communication built around the specific touchpoints of pool service. So the operator uses the generic software for scheduling, keeps a paper log for chemistry, emails homeowners manually when they remember, and maintains pesticide records in a spreadsheet their accountant built in 2019. They are technically using software. They are practically still running on paper.
The same pattern plays out in lawn care, where operators need EPA-formatted fertilizer application records but are using field service platforms designed for HVAC technicians. In third-party logistics, where 3PLs need multi-client inventory separation and automated client billing but are running warehouse operations on systems designed for single-client direct fulfillment. In healthcare operations, where clinical staff are using enterprise software built for administrators who will never see a patient. In every case, the horizontal tool covers eighty percent of the use case and completely misses the twenty percent that is operationally critical.
The depth advantage
When you build vertical software, you build the missing twenty percent. And the missing twenty percent is not decoration — it is the reason operators stay. Water chemistry history charts are not a feature a pool service operator uses once a month. They are the feature an operator checks on every visit for every pool because it determines what chemicals to add and what the pool will look like next week. Route optimization that accounts for pool size and chemistry complexity is not a nice-to-have. It is the difference between a technician finishing their route at 4pm and finishing at 7pm.
This depth creates structural retention that horizontal software cannot match. When an operator has been logging water chemistry data for two years in your platform, they have built institutional knowledge in your database. Their service history, their customer communication records, their compliance logs — all of it lives in your system and has real operational value that would be lost in a migration. The switching cost is not just a software migration. It is an information migration that operators know, instinctively, is dangerous. Horizontal software can match your feature list. It cannot replicate what two years of operation-specific data means to a business.
Why flat rate pricing accelerates vertical adoption
Vertical SaaS has a natural alignment problem with per-user pricing that horizontal platforms ignore at their peril. The typical operator in a fragmented vertical is a small business — a sole proprietor or a team of two to five people. Per-user pricing works against them in a specific and painful way. When they add a technician, their software cost goes up. When they expand to a second service area, their software cost goes up. The per-user model creates what is effectively a tax on growth, and operators in fragmented markets are acutely sensitive to that tax because their margins are thin and their growth is measured in individual customers, not revenue cohorts.
Flat rate pricing removes the growth tax. The operator who starts with your software at 50 customers pays the same as the operator who grows to 300 customers. That alignment — where the software company only wins when the operator succeeds — is not charity. It is a structural advantage that drives retention and word-of-mouth in markets where operators talk to each other constantly, compare software at industry associations, and trust peer recommendations over any marketing you could produce.
The market size is not the fragmentation
The most common objection to vertical SaaS is market size. Build horizontal, the argument goes, because any individual vertical is too small to build a real business on. This objection confuses the fragmentation of the software market with the size of the customer market. Pool service alone is 130,000 companies in the United States. Lawn care is 500,000. Healthcare operations — the operational layer below clinical care — involves millions of practitioners, administrators, and specialists, most of whom are using software built for a different job entirely. The fragmentation is in the software market, not the customer market. The customer market is enormous. The software market is fragmented because nobody built the right tool.
When nobody has built the right tool, the addressable market for the right tool is the entire industry. The first operator to offer pool service management software that actually works the way pool service works does not compete for a slice of the market. They compete for the whole thing, because the incumbents — the generic field service platforms and the legacy industry tools that have not meaningfully updated in years — are not competition in any real sense. They are the problem the operator is trying to escape.
Why now
Legacy software vendors have spent the last decade under private equity ownership. The pattern is predictable: acquisition, price increases, support cuts, feature stagnation. The operators who built their workflows around these tools are now paying more for less, and they know it. The switching cost they accepted five years ago — when the platform was functional and reasonably priced — looks different now that they are paying forty percent more and waiting three weeks for a support response.
This creates a specific market condition that did not exist ten years ago: operators in fragmented verticals who are not just open to switching, they are actively looking for alternatives. The friction of migration has not changed. But the pain of staying has increased to the point where the calculation has inverted. The operator who would have tolerated generic software and worked around its limitations in 2018 is the same operator who is ready to switch in 2026, provided someone offers them a tool that was actually built for their business.
That is what vertical SaaS offers. Not a better version of the same wrong tool. A tool built from the ground up around how the industry actually operates, priced in a way that rewards growth rather than taxing it, and supported by people who understand that the software works in the field or it does not work at all.
Fragmented markets reward depth. Depth wins over breadth when the customer's problem is specific enough that generic solutions consistently fail. And in the industries Drakos targets, the failure of generic solutions is not theoretical. It is documented daily in paper workarounds, abandoned software subscriptions, and operators who built successful businesses despite their software rather than because of it.