Powstania Warszawskiego 15
31-539 Kraków
A mechanical contractor runs two businesses under one name. The project side installs systems on job sites, with crews, phases and change work. The service side maintains those same systems for years afterwards. Most software is built for one side or the other, and the handover between them is where the data gets lost.
Mechanical contractor software has to serve both halves of the business: installation projects on construction sites and the service work that maintains those systems afterwards. Construction platforms are built for general contractors and field service platforms for service calls, so mechanical contractors often run two systems with a spreadsheet between them. Custom software makes sense when equipment installed on a project should become the service record automatically, when crew hours must land on phases and cost codes, and when change work has to be captured and signed on site.
Construction management platforms are designed around the general contractor: drawings, RFIs, submittals and schedules across many trades. Field service platforms are designed around the service call: a customer, an address, a technician and an invoice. A mechanical contractor needs both, but only a slice of each.
Crews working to a construction schedule, hours per phase, materials, extra work agreed with the general contractor, and a startup checklist when the system is commissioned.
Agreements, planned maintenance, emergency calls and repairs on equipment that is already running, very often equipment the project side installed.
Buying both platforms usually means paying for two large products to use a fraction of each, then keeping a spreadsheet to move data between them. The spreadsheet is the real system, and it depends on one person remembering to update it.
When an installation is finished, the crew starts the system up and records what they found: model and serial numbers, where each unit sits in the building, startup readings and photos of the work. It is the most valuable document the project produces, because it is the first page of the service history.
In practice it often ends up in a PDF sent to the general contractor, a shared folder, or a technician's phone. When the first service call arrives a year later, the service team starts from zero: which unit, which model, when the warranty began. The information existed. It never moved to the side of the business that needed it.
Every unit your crews install is a service customer you already have, as long as the software remembers it.
These records decide both the margin on the project and the quality of the service work that follows. Each one is cheap to capture at the moment and expensive to reconstruct later.
For a mechanical subcontractor, extra work is part of almost every project. A duct has to be rerouted because another trade got there first, equipment arrives different from the drawing, or the client adds a unit. The foreman agrees on the spot, because the schedule does not wait for a formal change order.
Whether that work is ever paid for depends on what was recorded at the time. A change ticket created on the phone, with photos, hours and a signature from the site representative, is a document the office can bill. A note in a foreman's memory becomes a negotiation months later, and it is rarely one the contractor wins.
This is one of the clearest cases for software built around your own process. Who may approve extra work, what the ticket must contain and how it reaches the project manager differ between contractors, and between the general contractors they work for.
When install and service records share one system, the first service visit starts differently. The technician opens the unit and sees what was installed, when it was started up, the commissioning readings and the warranty dates that follow from them. The office can offer a maintenance agreement on equipment it already knows, instead of surveying the building again.
From there, the service side works like any HVAC service operation: agreements tied to equipment, planned visits and coverage applied at the invoice. That part is described in detail in service agreements in custom HVAC software.
The closest work we have shipped is TimeFix, a workforce app for electrical contractors: a Flutter app for crews and a web panel for team leads. Two lessons from it apply directly to mechanical contractors.
First, real requirements appear on site. The work timer had to keep running when the screen was locked or a call was placed from inside the app, and that requirement came from real jobs, not from the specification.
Second, crews build workarounds quickly. Before the app covered one particular case, technicians started writing things down in their phone's notepad, and within days the data in the system no longer matched the work.
Plant rooms, basements and risers rarely have signal, so the job, the equipment list and the checklists have to be on the phone before the crew arrives. Photos go into their own upload queue, separate from the form data, so a weak connection never holds back a finished record. The approach is described under offline first app development.
If your business is almost entirely residential service, a standard field service platform will fit and cost less. If you only install and never maintain, a construction platform or a disciplined spreadsheet may be enough.
Custom software pays off when both sides are significant, when the same buildings and equipment move from projects to service contracts, and when the data has to reach the accounting system you already use. The signals are listed in when you outgrow field service software.
The first release connects the two sides instead of replacing everything. Estimating, accounting and drawings stay where they are.
Dispatch for emergency calls, a customer portal and inventory per site can follow once crews use the basics every day. How we scope and deliver these projects is on our construction app development and custom HVAC software development pages, and the service side is covered under field service app development.
Software that supports both sides of a mechanical contracting business: installation projects on job sites, with crew hours, equipment, change work and commissioning, and the service work that maintains those systems afterwards.
Most are built for general contractors and focus on drawings, RFIs and schedules across trades. A mechanical subcontractor typically uses a small part of them and still needs a separate system for service work.
Field service platforms handle calls, agreements and dispatch well, but rarely cover project work: hours per phase, extra work agreed with the general contractor, and commissioning records that should become service history.
Yes, if the job, equipment list and checklists are loaded onto the phone before the crew arrives. Records and photos sync when coverage returns, with photos in a separate upload queue.
No. A first version usually exports or writes hours, change work and service invoices into the accounting system you already use. Estimating and drawings stay in their current tools.
A first version connecting crew work, commissioning and the service record typically takes 10 to 14 weeks. A fuller system with dispatch, offline reporting and an accounting integration takes 14 to 22 weeks.
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Walk us through how a job moves from the install crew to the service team today. We will tell you what the first version should connect, and what can stay where it is.
30 minutes, no preparation needed.