What Building PolarPath for HVAC Contractors Taught Us About Software Nobody Asked For

There is a moment in every software project where you realize the thing you built is not the thing the customer actually needed. For most software companies, that moment comes after launch, and it is expensive. We got there a little earlier, but only because a real HVAC contractor sat down with us and walked us through a Tuesday.

Not a hypothetical Tuesday. A real one, reconstructed from memory, with real chaos in it.

The Tuesday That Rewrote Our Assumptions

The contractor was running a mixed operation: reactive service calls and multi-week mechanical projects running simultaneously. Maybe fifteen field technicians, a dispatcher, a project manager, and an owner who still handled the bigger customer relationships personally.

We walked in expecting to validate a workflow we had already mapped. The map was logical. Clean. It moved left to right: intake, quote, dispatch, complete, invoice.

The actual Tuesday looked nothing like that.

By 9 a.m., a technician on a planned preventive maintenance run had found a failing compressor on a rooftop unit. That was now a reactive call embedded inside a scheduled project visit. The dispatcher needed to extend that tech's time on site, which meant pulling him from an afternoon service call, which cascaded into a customer callback, which landed back on the owner's phone. Meanwhile, the project manager was chasing an RFI response from a general contractor on a different site, the original PM call was going unbilled because nobody had created a change order for the compressor work yet, and payroll cut-off was Friday.

The software they were using at the time: a field-service dispatch tool, a separate project management board, a shared Google Sheet for change orders, QuickBooks for invoicing, and text messages for everything in between.

The humans in that shop were the integration layer. They were the middleware.

What We Got Wrong First

When we started building PolarPath, we treated the service workflow and the project workflow as two separate modules that would hand data off to each other. Clean seams. Clear handoffs.

That was the wrong mental model.

Here is what we learned: in a mixed field-service and project business, the handoff IS the problem. Not the individual tools. The gap between them. And when you build two modules with a clean seam in between, you have built a digital version of the same problem you were trying to solve.

The compressor-on-the-rooftop scenario is not an edge case. It happens constantly in HVAC, mechanical, and facilities management work. A planned visit reveals unplanned work. A service call turns into a project scoping conversation. A change order gets verbal approval on site and then floats in limbo until someone remembers to bill it, which is sometimes never.

We kept hearing versions of this from contractors:

• "We do the work and then we piece together the invoice afterward."
• "The tech knew about the change. The PM knew about the change. Finance found out two weeks later."
• "We probably left money on the table but I couldn't tell you exactly where."

This is not a people problem. It is a structural problem. When operational truth lives in multiple disconnected systems, no single person has the full picture, and the cost shows up as unbilled work, delayed invoicing, and margin that erodes quietly.

The Lesson: Design for the Bleed, Not the Boundary

The phrase we started using internally was "design for the bleed." The messy overlap between service and project is not an exception to handle. It is the core of what these businesses do. The software has to be built for that overlap as the primary case, not the edge case.

What does that mean in practice? A few things we changed:

1. A work order and a project task need to share the same operational context

If a technician on a project visit generates a new work order for unplanned work, that work order needs to know it belongs to the same customer, the same site, and the same billing relationship. The field data that flows from it, time, materials, photos, notes, needs to be available to whoever creates the invoice without anyone re-keying anything.

2. Change orders need to be created at the moment of discovery, not after the fact

This sounds obvious. In practice, most contractor shops have a process where the change order gets documented later, at the office, based on what the tech communicated over the phone or in a text. By then, details are soft. Approvals are informal. Billing gets complicated.

The right point of capture is in the field, at the moment the scope change is identified, with enough structure that it creates a real paper trail without slowing the tech down.

3. Dispatch visibility needs to span both service and project

A dispatcher who can only see service calls is flying partial instruments. If your project team has a tech allocated to a site all afternoon and your dispatch tool doesn't know that, you will double-book. We saw this happen. The fix is not better communication between the dispatch lead and the project manager. The fix is one view of workforce allocation that covers both.

4. Invoicing should be a byproduct of field execution, not a separate effort

In the shops we worked with, invoicing was downstream of everything else. Someone had to take what the tech reported, cross-reference the work order, add any change orders, confirm materials, and then build the invoice. That process took time, introduced errors, and meant that days-to-invoice stretched out. In some cases, change orders slipped through unbilled entirely.

When field data flows directly into billing without a manual assembly step, you close that gap. Not all of it, but most of it.

A Simple Framework for Diagnosing Your Own Middleware Problem

If you are running a mixed service and project operation and you want to get a rough sense of where your human middleware is costing you the most, try this:

1. Map your last five change orders. Where did they originate? Who captured them? When did finance first know about them? How many got billed?

2. Track one project visit with an embedded service call. Time how long it takes from that unplanned work being identified to an invoice going out. Count the handoffs.

3. Ask your dispatcher and your project manager the same question: who is on site at 2 p.m. Thursday? If they give you different answers, or if it takes them more than thirty seconds to find out, you have a visibility problem.

4. Look at your last month of closed work orders. How many have open billing items? This number tells you more about your operational health than almost any other metric.

None of this requires new software to diagnose. A spreadsheet and an honest conversation with your ops lead will surface the gaps. The question is whether you then fix those gaps by adding another tool (and another handoff) or by consolidating the workflow.

Where PolarPath Fits Into This

What we built, after that contractor walked us through their real Tuesday, is a platform where service and project operations share the same operational layer. Work orders, project tasks, change orders, field time, materials, and invoicing all live in one continuous workflow. QuickBooks stays as the accounting system of record. PolarPath owns the execution layer where the actual business events happen.

That means when a compressor gets flagged on a rooftop during a planned PM visit, the tech can create a change order on site, the dispatcher can see the adjusted schedule, the project manager has the documentation, and the invoice can be built from real field data when the work is done. Nobody re-keys anything. Nothing floats.

That is the thing we learned. Not a feature. A structural principle: the integration between service and project can't be a handoff. It has to be the same surface.

The Takeaway

If your business does both reactive service and planned projects, your biggest operational risk is not in either workflow individually. It is in the gap between them. That gap is staffed by humans re-entering data, chasing approvals, and trying to keep two separate systems synchronized.

Before you add another tool, ask whether the tool creates another seam, or closes one.

If you want to see how PolarPath handles the mixed model in practice, book a walkthrough at polarpath.ca.