Powstania Warszawskiego 15
31-539 Kraków
Off the shelf platforms model a service business as jobs, technicians and invoices. An HVAC business runs on maintenance agreements, equipment histories, refrigerant records and a summer that behaves nothing like February. We build the parts of that which no platform has a field for, on a fixed price agreed before development starts.
30 minutes with the founders. No preparation needed.
Scheduling, dispatch boards, invoicing and customer records are solved problems. If you are running a general field service platform today, keep it. Replacing a working system of record with a custom build is a bad trade, and any supplier who suggests otherwise is quoting their own capacity rather than your situation.
The trouble starts where an HVAC business stops looking like the generic service company those platforms were designed around. That point arrives sooner than most owners expect, and it shows up as three habits rather than as a complaint about the software: a spreadsheet running beside the system, a notes field carrying decisions that no report can read, and somebody whose day is spent translating between two tools.
Each of those is the same symptom. A rule your business runs on has no field to live in.
These come up on almost every HVAC scoping call we run. If two or more of them describe a daily headache in your operation, that is your build case.
The system of record stays where it is. What we build is the part that carries your rules and the part your technicians hold, because that is where adoption is won and where off the shelf cannot reach.
Today's jobs, equipment history on arrival, the job form with its validation, photos, readings, signature and time capture, all working through a full day without coverage.
Entitlements, covered visits, renewal dates and the list of agreements that are about to lapse, in a report the office can act on rather than a spreadsheet someone maintains.
Unit level history, warranty status, refrigerant added and recovered, and the documentation trail exported in a form that stands up when somebody asks for it.
Your assignment logic applied on top of the scheduler you already pay for, so the rules live in software rather than in one dispatcher's head.
This is the part that is invisible in a demo run over office wifi, and it is where custom work earns its cost on an HVAC project.
Run this over five working days on your own operation, without telling anybody it is a software evaluation. It answers the question better than any vendor comparison, including ours.
The long version of this reasoning, including where off the shelf genuinely wins, is in our guide to building or buying field service software. If almost nothing survives the test, configure what you own and revisit in a year. We will tell you that on the call.
Every quote is specific to your scope, so treat these as the bands rather than a price list. What moves the number is the number of integrations and how much of the operation the software has to carry.
A narrow first release around a single flow, usually the technician app against your existing platform. Ten to fourteen weeks.
Technician app plus backend, equipment history, forms with validation, offline queue and a back office view for the team.
Agreement tracking, dispatch rules, compliance records and integration with the systems you already run. Fourteen to twenty two weeks.
The drivers behind these numbers are broken down in five key cost drivers for field service apps, and how the fixed price itself works is on our fixed price app development page.
You walk us through the operation: how agreements work, how dispatch decides, what the office chases. We ask what usually goes wrong in HVAC operations of your size and tell you what is realistic. No pricing yet.
Before scoping anything we look at your existing platform's API: which objects can be written and not only read, the rate limits, whether it pushes events or has to be polled, and whether custom fields are exposed. That check takes days and it decides what is possible.
The conversation becomes a document with the flows, the business rules and the conditions the app has to survive. One number for the whole scope, with acceptance criteria and the defect versus change request definition written into the contract.
Live demos every two weeks. Your own technicians use the app on real jobs during development, which is when the requirements that could not have been written down appear, while there is still room in the schedule for them.
Store submission where the app is public, or distribution to your team where it is internal, then a signed acceptance protocol closing delivery. Code, credentials and infrastructure transfer to you. On larger contracts the one year warranty starts here.
Delays on field service projects are rarely engineering delays. They come from the client side and they are predictable, so we name them before the contract rather than explain them afterwards.
Tell us how agreements, dispatch and paperwork run today and what the workarounds cost you. You get a straight answer on what your current platform could absorb with configuration, what justifies building, and a written scope with a fixed price for whatever is left.
30 minutes with the founders. No preparation needed.