What Building for Real HVAC Contractors Taught Us About Software (A Founder Build Note)

There is a version of software that looks great in a demo and quietly fails in the field. The screens are clean, the workflow makes logical sense, and then a real dispatcher sits down and within twenty minutes they have found three situations your data model never anticipated. This is not a knock on any particular tool. It is just what happens when you build from the outside looking in.

We have been building PolarPath from the inside, working directly with HVAC and mechanical contractors who do both reactive service calls and planned projects at the same time. That mixed model, one company handling a boiler repair on Tuesday and managing a multi-phase mechanical fit-out on the same schedule, turns out to be the stress test that exposes every assumption you carry into the room.

This post is an honest account of one lesson that changed how we think about software for field-service and project operations. No invented numbers. No tidied-up retrospective. Just what we found.

The Assumption We Carried In (And Had to Abandon)

When we started, we operated on a reasonable assumption: that service and projects are two different modes of operation, and a contractor switches between them depending on the job type.

In practice, that is wrong.

For a mid-size HVAC company in the GTA, a single customer relationship can contain a service contract, a reactive emergency call, and an active capital project running at the same time. The same crew lead might close out a service work order in the morning and submit a change order RFI on a mechanical project in the afternoon. The same dispatcher is handling both the break-fix queue and the scheduled project milestones. The same project manager is watching a Gantt chart while also fielding calls about a compressor that failed overnight.

These are not separate workflows that occasionally touch. They are one continuous operational reality. The people, the trucks, the revenue, the margin, and the compliance obligations are all shared. Building them as parallel tracks, with a clean handoff between "service mode" and "project mode," created friction exactly where the real work happens.

So we had to rebuild the model.

What We Rebuilt, and Why It Matters Operationally

The core change was moving away from "job type" as the organizing principle and toward the customer relationship and the revenue event as the organizing principle.

Here is what that means in practice, and why it matters for any contractor thinking about how their own systems are structured.

1. The Quote Has to Know What It Might Become

A quote for a service repair and a quote for a phased mechanical installation look different on paper, but they can both originate from the same customer, the same site, and sometimes the same service call that uncovered a larger problem. If your quoting tool is separate from your project management tool, you are manually re-keying scope into two different systems the moment that service call turns into a capital project. That re-keying is where scope gets lost, change orders get missed, and the original quoted margin becomes a fiction by the time the job is done.

What we learned: the quote has to carry its context forward. Who asked, what site, what was already on-site, what the field tech observed. That way, when scope changes, you are amending a living record, not starting over.

2. Change Orders Are Where Margin Lives (and Dies)

This is the single most consistent finding from working with contractors directly. The original contract margin is a plan. What actually gets billed determines whether the job made money.

Every HVAC and mechanical contractor we talked to had a version of the same story: a change order was done in the field, the tech documented it on paper or in a text message, and somewhere between the job site and the invoice it either got billed late, got billed at the wrong amount, or did not get billed at all. Not because anyone was careless. Because there was no single system that carried the field event through to the invoice without a human manually completing the relay.

The operational fix is not a reminder email. It is removing the relay entirely. Field event (change order approved on site) creates a billing item. Billing item flows to the invoice. Invoice goes to the customer. The human reviews and approves; they do not re-enter the data.

When we rebuilt around this principle, the change order workflow stopped being a post-job reconciliation exercise and became part of the job itself.

3. Dispatch Cannot Be Blind to Project Commitments

In a service-only shop, dispatch is about matching the right tech to the next call. In a mixed model, dispatch is also about not accidentally pulling a crew lead off a scheduled project milestone to cover a reactive call, or double-booking a specialized tech who is already committed to a two-day commissioning job.

The problem is that most dispatch tools only see the service queue. The project schedule lives somewhere else, in a spreadsheet or a standalone project management tool. So the dispatcher is doing calendar arbitrage in their head, and when they get it wrong, either the project slips or the service customer waits, and either way someone is on the phone explaining the situation.

The fix is not giving dispatchers more information to juggle. It is giving them one view where service availability and project commitments are visible together. When we built that view, dispatchers stopped making avoidable conflicts, not because they got smarter, but because they stopped being asked to hold the whole schedule in their head.

A Simple Framework for Auditing Your Own Workflow

You do not need new software to do this audit. You need twenty minutes and honest answers.

Walk one completed job backwards from the invoice to the original customer request, and ask:

1. How many times was the same piece of information entered into more than one system?
2. Where did a human have to chase something down (an approval, a document, a field note) before the next step could happen?
3. What billable items could have been missed if the person doing the chasing had been busy that day?

Most contractors who do this exercise find two or three points where the workflow depends on a specific person's memory or habit rather than a system. Those are your risks. A tech quits, a dispatcher goes on leave, a project manager gets pulled onto something urgent, and the institutional habit disappears with them.

The goal is not to eliminate human judgment. It is to make sure the critical handoffs are held by a system, not by a person's good intentions.

Where PolarPath Fits Into This

PolarPath is built on the conclusion we reached after running this exercise with real contractors. The entire chain, from the first customer contact through quote, dispatch, field execution, change orders, project milestones, invoicing, and collections, runs in one platform. QuickBooks stays as the accounting system of record; PolarPath owns the operational layer where the business events actually happen.

The specific problem we kept solving for is the moment where a field event should create a billing item and something in between breaks the connection. We have wired that connection across service work orders and project change orders both, because in a mixed-model shop they are the same problem.

If your shop runs both service and projects and you are manually reconciling them at month end, that reconciliation is costing you billable hours and margin. The question is just how much.

The Practical Takeaway

Building software for contractors has taught us that the most expensive problems are usually invisible ones. Not the call that did not get dispatched, which someone notices immediately. The change order that got done but never billed. The project milestone that slipped because dispatch pulled the crew. The quote that went stale because no one had a prompt to follow up.

These are workflow problems, not people problems. And workflow problems have workflow solutions.

If you are an ops lead or owner at an HVAC, mechanical, or electrical shop and you want to run this audit on your own business, start with the last five completed jobs and work backwards from the invoice. You will find the gaps faster than you expect.

Interested in seeing how PolarPath handles the operational layer for a mixed service and project shop? Book a walkthrough at polarpath.ca.