Every pool service technician carries two things that don't talk to each other: the app their company bought for scheduling, and a paper log they fill out by hand for chemical readings. The app doesn't know what was dosed last Tuesday. The paper log doesn't connect to the invoice. The customer calls asking why their pool turned green, and nobody can pull up the chemical history for that specific pool without digging through two systems and a shoebox of tickets.
Pool service software has existed for years. Most of it treats pools like addresses on a dispatch ticket — which is how you end up with a touring route manager bolted onto a generic service platform that has no idea what free chlorine is. The U.S. pool service industry generates over $6 billion annually, and most of it still runs on tools built for a fundamentally different business model.
The Weekly Service Model Changes Everything
Pool service is not field service in the traditional sense. It's a recurring route business with chemistry compliance requirements. A technician servicing 80 pools per week visits each pool on a fixed schedule, tests the water, adjusts chemical levels, cleans the equipment, and logs what they found and what they did. That cycle repeats every week, every season, for years.
The data model for this is completely different from a standard field service ticket. Each pool has its own chemical history, equipment specifications, notes about the owner's preferences, and a service record stretching back through multiple visits. When a tech shows up to pool number 47 on Tuesday, the app needs to show them: what the readings were last week, what was dosed and when, what equipment issues were flagged last month, and what the customer's seasonal notes say. None of that exists on a standard dispatch ticket.
Generic vertical SaaS tools built for dispatch-based field service miss this entirely. They optimize for ticket creation and tech routing. The chemical log, the equipment history, and the per-pool service record are afterthoughts — usually a notes field that nobody reads.
What Pool Service Software Actually Has to Do
A purpose-built pool service platform needs to handle six things that generic tools handle poorly or not at all.
Route optimization with stop sequencing. Efficient pool routes aren't just about shortest distance — they account for pool size, service time, chemical load, and customer preferences for time windows. The software needs to understand the physical reality of the route, not just the map.
Per-pool chemical logs with dosing history. Every pool gets its own chemical record. pH, alkalinity, chlorine, cyanuric acid — each reading needs to be timestamped against which technician ran it, what they dosed, and what the water looked like before and after. That history is the diagnostic record when something goes wrong and the compliance record if a commercial account asks for documentation.
Equipment service records by serial number. Pumps, filters, heaters, and salt cells each have their own service history and replacement cycles. When a tech notes that the pump is making a grinding noise, that observation needs to attach to that specific pump's record — not to an address, but to the equipment with its serial number and installation date.
Customer-facing service reports with photos. Homeowners and HOA managers want to know what was done and what was found. A photo of the filter pressure gauge before and after cleaning, the before-and-after water test results, and a note about the leaf basket clog takes two minutes to generate if the software supports it. Without it, every service question becomes a phone call the office has to handle.
Recurring billing tied to service completion. Pool service billing is monthly and recurring, but it should tie to confirmed service visits — not to a calendar date. If a technician skips a pool, that visit shouldn't bill. If a customer adds a one-time repair, it should roll into that month's invoice. The billing logic in generic platforms doesn't handle this cleanly.
Chemical inventory across technicians. A company running five routes goes through hundreds of pounds of chemicals per week. Knowing what each technician is carrying, what they used, and what they need to restock requires inventory tracking at the technician level.
Market Size and Distribution in a Fragmented Industry
The pool service market has approximately 67,000 companies in the United States. Most of them run between 50 and 500 pools. At $150 per technician per month, a shop running four technicians on 320 pools is $600 per month. A 1,000-customer base is $600K ARR — a real business with strong retention dynamics.
Switching costs in this market are high. A pool service company's customer database, chemical history, and equipment records represent years of accumulated data. Operators don't migrate that lightly. Distribution in this market moves through the industry network — regional pool associations like APSP chapters, distributor relationships with companies like SCP Pool Corporation, and referrals between operators. An operator founder with 10 years of industry relationships reaches the first 50 customers through conversations, not ads.
Why the Operator Founder Wins Here
Pool chemistry has edge cases that software builders outside the industry consistently get wrong. The relationship between cyanuric acid and chlorine effectiveness isn't obvious unless you've managed pools through a Texas summer when stabilizer levels creep too high. The service sequencing logic — what order you test, dose, and clean in — matters for accuracy and for whether the tech finishes the route on time.
The operator founder in this market is a pool service company owner or operations manager who has run routes, managed technicians, and dealt with the software gap firsthand. They know which existing tools their competitors use and why those tools fall short. They have relationships with distributors, association contacts, and the owners of other pool service companies who would try a better product if someone they trusted built it.
If you've run pool service routes and you've been living with the gap between the software and the reality of the work, tell us what you'd build. The thesis is there. We want to hear the specific workflow you'd fix.