Window cleaning software for rounds that refill themselves.

Window cleaning management software runs the recurring side of a window cleaning business. It keeps the round: which customers repeat, how often, and in what order. It holds the route for each crew day, the pane-based quote for each property, the plan for a rain day, and the invoice that follows each completed visit. The point is that the round keeps running without the dispatcher holding it together from memory.

Pressure washing work is usually a one-off job: measure the surface, quote it, do it, invoice it. Window cleaning lives on repeat rounds. The same customer comes back every four, six, or eight weeks, the ticket is small, the stop count is high, and a rain day moves a whole day of jobs at once. A business that sells both services can run them in one system, but the round logic is what makes window cleaning different, and it is the part a one-off quoting tool does not model.

Five things. Repeat rules with pauses, skips, and cancellations that behave correctly. Pane-level pricing that reprices when a crew counts differently on site. Routes grouped by street so a crew is not crossing town between stops. Rain-day moves that shift a whole day and tell every affected customer. And commercial billing where several sites roll up to one parent invoice. If a tool misses two of those, your office is keeping the difference in spreadsheets.

Buy when a maintained product handles your rounds, routes, quotes, and billing with reasonable setup. Jobber, Housecall Pro, The Customer Factor, and Squeegee all serve window cleaners, and each fits a different size of operation: a solo round, a growing residential book, or a larger crew. Build custom when the way you work breaks the tool: commercial accounts with many sites under one bill, several crews that need true route planning together, franchise territories, or pane pricing rules the product cannot express. Our build vs buy guide works through that decision with real cost bands.

For a small, well-defined task with someone technical managing it, freelancers are often cheaper. The pattern that goes wrong is a non-technical buyer coordinating several freelancers becoming the project manager, the tester, and the person who discovers the pieces do not fit. A window cleaning management software build earns its fee when the work needs coordination across rounds, routes, quotes, billing, and the crew app: one accountable party, one phase price, and checkpoints against the whole round. If your need is one screen or one fix, hire the freelancer.

The first paid phase may cover a bounded audit, a proof of concept, a recovery plan, or a small first release, and first phases start at $10000. A full first platform is a larger engagement: our build vs buy guide puts a working first version covering recurring scheduling, route planning, pane-based quoting, a crew app, and a customer portal at $90,000 to $160,000 over 10 to 14 weeks. The agreed phase is priced in writing before it starts.

Timing depends on scope: a bounded audit or proof of concept is a smaller engagement, while a full platform with several crews, commercial contract billing, and a customer portal takes longer. Our build guide puts a working first version at 10 to 14 weeks. The schedule is set once the first round and what 'done' looks like are clear.

Rain cancels a day, not a customer. The whole day shifts together: the jobs move to the next open slot, the route re-forms around the moved stops, and every affected customer gets the new time by text. The dispatcher moves the day in minutes instead of calling each customer one by one, and nothing falls off the calendar quietly. No off-the-shelf tool we reviewed handles this automatically, so in a custom build it is designed in from the start, not added later.

Each customer carries a repeat rule, not a list of separate jobs. When a customer pauses, the system stops making new visits and resumes from the right point in the cycle when they return. A skip moves one visit and leaves the rest of the cycle alone. A cancellation clears the future visits. A frequency change, from every six weeks to every eight, recalculates the visits ahead. The rule is the record, so the round cannot drift out of step with what the customer agreed.

Yes. The quote comes from pane count, pane type, floor level, and whether the work is inside, outside, or both. The pricing rules sit in one place, so every quote follows the same logic. When a crew visits a property and counts panes differently, the quote reprices from the same rules and the customer can see why the price changed.

A commercial account is one parent with several sites under it. Each site keeps its own schedule, access notes, and contact, and each visit is recorded against its own site. The invoice rolls up to the parent, and contract prices override the standard quote rules for that account. That is the part generic tools handle worst: they bill by location, so the office ends up adding the sites together by hand.

Yes, for the workflows the crew actually needs. The crew app shows today's stops in order, with access notes, gate codes, and property warnings. Crews take before and after photos, mark jobs done, and record a changed pane count on site. The app keeps working with no signal and syncs when the connection returns, so the office sees the same record the crew sees.

Two things, and both are decided early. First, the repeat rule gets added after the scheduling is built. Retrofitting frequency rules onto a system that stores each job separately creates duplicated visits, pauses that break the cycle, and cancellations that leave future jobs behind. Second, route planning that is not really planning: picking the closest next stop at each step produces routes far worse than a proper solver on a full crew day. Both are fixed by designing the repeat rule and the route planning before the first screen is drawn.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the round agreed at the start: a repeat rule that survives a pause, a rain day that moves cleanly, a quote that reprices when the pane count changes. Progress is reported in plain language: what changed, what's next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your business.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

Yes. Takeover is a common first engagement, and it always starts with an audit: where the code lives, how your data is organized, what is tested, which outside services it depends on, who can access what, and how updates go live. Code that is understandable and fit for the next release stays; only the parts blocking reliability get replaced. And if you already paid another vendor and have nothing working, the audit tells you which story you have before you spend more: the most expensive version is the product that looks finished, clean screens and clicking buttons, while underneath nothing is tested and the security checks run in the browser, where anyone can tamper with them, instead of on the server where they hold.