How to Build Window Cleaning Management Software

Window cleaning companies do not struggle to find work. They struggle to manage it. A residential window cleaner with 200 recurring customers is coordinating job schedules across four crews, routing 12 stops a day, pricing jobs by pane count and floor level, and chasing invoice payments. Most of this happens in spreadsheets and phone calls.

According to IBISWorld's field services industry analysis, the US window cleaning industry generates over $2.5 billion in annual revenue, with the majority of that split between small operators running 2-10 crews. That operator profile is exactly who benefits most from custom scheduling software -- once they've outgrown Jobber.

RaftLabs has built recurring scheduling and field service platforms for operators at exactly this scale. The problems below are the ones we've seen break the most often.

The software to fix that is not complicated in concept. But the execution has several hard parts that most teams underestimate. This post covers the four core systems, the hardest engineering problem, and realistic cost and timeline estimates.

What window cleaning software actually needs to do

Before getting into architecture, define scope. Most window cleaning operations need:

• Recurring job scheduling (monthly, quarterly, annual cycles)

• Route optimization for multi-stop, multi-crew days

• Quote and estimate builder

• Before/after photo documentation per visit

• Customer portal (upcoming schedule, invoices, payment)

• Crew mobile app (job details, photo upload, completion sign-off)

• Crew management (assign jobs to specific crews, not just individual cleaners)

Larger commercial operators also need:

• Commercial contract management with multi-location accounts

• Frequency schedules per location under a parent account

• Chemical and equipment tracking per crew vehicle

• Compliance documentation for commercial properties

Define which of these you need before writing any code. The MVP and the full platform have different architectures in key places.

The four core systems

1. Recurring job scheduler

Most window cleaning is recurring. A residential customer books quarterly exterior cleaning. The job happens in March, June, September, and December. They should not have to rebook each time. You should not have to manually create four jobs.

The scheduler generates future jobs from a frequency rule. Think of it like RRULE in calendar systems. Each customer record has a service frequency (monthly, every 6 weeks, quarterly, annually), a preferred day of the week or week of the month, and a preferred crew.

The scheduler runs on a cron job. Monthly customers: generate jobs 30 days out. Quarterly customers: generate 60 days out. Annual customers: generate 90 days out. Jobs appear on the dispatch calendar automatically.

The edge cases are where this gets difficult. More on that in the hardest problem section below.

2. Route optimizer

Google OR-Tools documentation describes the Vehicle Routing Problem as NP-hard. That means no algorithm finds the perfect solution for large datasets, but a good solver finds routes within 2-5% of optimal in seconds. At 10 crews each doing 12 stops, a 5% route improvement saves roughly 45 minutes of drive time per day across the fleet.

A crew does 8 to 14 stops per day. The sequence of those stops determines how much time is spent driving and how many jobs the crew can complete. A bad route wastes an hour of drive time per day.

Route optimization for multi-stop, multi-crew days is a Vehicle Routing Problem (VRP). The correct tool is OR-Tools, an open source solver from Google. You feed it job locations, crew start and end depot addresses, time windows per job, and estimated job durations. It returns the optimal route for each crew.

Run optimization nightly for the next day's jobs. Allow dispatchers to lock specific job sequences when a customer has a hard time window. Locked jobs are excluded from optimization.

Do not build a simple nearest-neighbor algorithm and call it route optimization. It will not find the best routes, and crews will notice.

3. Quote and estimate builder

Window cleaning pricing is not a flat rate. Price is a function of:

• Pane count per property

• Pane type: standard, French panes, skylights, solar panels

• Floor level: ground floor, second floor, third floor or higher

• Interior vs exterior (some customers do exterior only)

• Residential vs commercial pricing tiers

Build a configurable pricing matrix. Each pane type and floor level combination has a base unit price. The quote engine multiplies pane counts by unit prices and sums the result. Discounts apply at the job or account level.

For commercial accounts, pricing is often negotiated and stored on the contract, not calculated from the matrix.

Store quote history per property. When a crew visits the property to verify a quote, they can update pane counts from the mobile app. The updated count re-prices the job automatically.

4. Customer portal and crew mobile app

The customer portal is straightforward: upcoming scheduled visits, invoice history, payment, and the option to pause or cancel service. This is what customers actually want from software. They want to see when you are coming and pay online.

The crew mobile app needs:

• Today's job list with addresses and sequence

• Navigation link to each stop (Google Maps deep link)

• Property details: access instructions, gate codes, customer preferences

• Photo capture for before and after each job

• Completion confirmation and customer signature (for commercial)

• Chemical and supply usage per vehicle (for tracked fleets)

Build the mobile app as a React Native app or a progressive web app. PWA is faster to build and easier to maintain. Native is better if crews have unreliable data connections, because a native app can queue actions offline and sync when connectivity returns.

The hardest problem: recurring job generation at scale

"The number one reason field service software projects fail is that the recurring job model is bolted on after the core scheduling system is built. Retrofitting frequency rules onto a poorly modeled job table costs three times what building it correctly from the start would have." -- Gene Marks, small business technology columnist for The Guardian and Forbes, writing on field service software selection.

A company with 500 recurring customers cannot manually create 500 jobs each month. They cannot manually create 125 jobs each quarter either. The system must generate jobs automatically and correctly.

Here is where it breaks down without careful design:

A customer changes frequency from monthly to quarterly. There are two already-generated monthly jobs in the future. The system must cancel the next monthly job and keep only the correctly spaced quarterly jobs going forward.

A customer pauses service for six weeks while they travel. The system must stop generating jobs during the pause period and resume from the correct point in the cycle when they return, not from the date they cancelled.

A crew is unavailable on a scheduled date because of a public holiday. The system must reschedule all jobs assigned to that crew to the next available day, without losing the customer's ongoing cycle. If the customer is monthly and the first available day is the 5th instead of the 1st, next month's job should still target the 1st, not shift to the 5th.

A customer cancels. The system must cancel all pending and future generated jobs, not just the next one.

The correct design: store the frequency rule and the next-due date on the customer record. The job generator creates jobs from the rule, never modifying the rule itself. When frequency changes, pauses, or cancellations happen, they update the rule and the next-due date. The generator respects whatever the rule says at the time it runs.

This is not technically exotic. But it requires clear data modeling before you write the first line of scheduling code. Retrofitting this logic onto a poorly modeled schedule is expensive.

Build vs buy

Jobber's published pricing shows their Connect plan at $69/month and their Grow plan at $249/month. At 15 crews, that pricing structure breaks: you're paying $3,000/year for a tool that can't model your commercial contracts or optimize routes across multiple crews.

Off-the-shelf tools to consider:

• Jobber ($69-$249/month): good for simple scheduling and invoicing, basic recurring jobs, route view. Lacks the commercial contract layer and advanced route optimization.

• ServiceM8: similar to Jobber, strong mobile app, Australian-focused.

• Housecall Pro: residential-focused, easier to use, limited commercial contract support.

Build custom when:

• You run five or more crews and multi-crew route optimization is a daily need

• You have commercial accounts with multi-location contracts

• You are building a franchise or multi-market operation where each franchisee needs their own instance with shared reporting

• You want ownership of customer data and pricing logic without per-seat licensing costs

For a single owner-operator with two crews, Jobber is the right answer. For a company with 10 crews and 30 commercial accounts, custom software will outperform generic tools within a year and pay for itself.

Cost and timeline

MVP: Recurring scheduling, pane-based quoting, route optimization, crew mobile app, customer portal, basic reporting.

• Timeline: 10-14 weeks

• Team: 2 senior backend engineers, 1 frontend engineer, 1 designer

• Cost: $90,000-$160,000

• Infrastructure after launch: $800-$2,000 per month

Full platform: Everything in the MVP plus commercial contract management, multi-location accounts, chemical and equipment tracking per vehicle, before/after photo documentation stored per visit, franchise multi-tenant support, and advanced analytics.

• Timeline: 18-24 weeks

• Team: 3 senior backend engineers, 1 frontend engineer, 1 mobile engineer, 1 designer

• Cost: $180,000-$300,000

• Infrastructure after launch: $2,000-$5,000 per month

The biggest cost driver between MVP and full platform is commercial contract management and multi-tenant franchise architecture. If you do not need those, the MVP covers most operational needs.

Technology stack

Backend:

• API: Node.js or Go

• Database: PostgreSQL (jobs, customers, properties, contracts, routes)

• Job generation: cron-based scheduler reading frequency rules

• Route optimization: OR-Tools (Python service or via Node.js bindings)

• File storage: S3 for photos

Frontend and mobile:

• Web dashboard and customer portal: React

• Crew mobile app: React Native or PWA

Infrastructure:

• Vercel or Railway for the API

• Managed PostgreSQL: RDS or Supabase

• S3: AWS or Cloudflare R2

The decision most teams skip

Before building, answer this: how many crews do you have today and how many in two years?

If the answer is under five and you do not have commercial multi-location accounts, use Jobber and spend zero dollars on custom software. Put that money into marketing.

If the answer is ten or more crews, franchise territory expansion, or commercial contracts that generic tools cannot model, build custom. The per-seat costs of off-the-shelf tools at scale, plus the operational friction of fitting your business into software built for a different business, will exceed the cost of a custom build within two to three years.

RaftLabs has built field service platforms and recurring scheduling systems across multiple industries. See our SaaS platform engineering service or talk to us about your architecture.