The Five Things That Set the Price of a Custom Build

Every owner asks how much it will cost. The honest answer rides on five things, and most of the nasty surprises trace back to one of them getting waved through at the start. Our pricing page shows both fixed CAD bands. Below are the drivers, each one the pattern we see across the field-service builds we run.

The Five Cost Drivers

How many systems have to talk to each other. A standalone tool, built once, depending on nothing outside itself, is the cheapest shape a build takes. The price climbs the moment it has to connect to something you already run. A desktop accounting package is the integration that eats the most scope, since it usually means matching totals to the cent and guarding against the same job getting invoiced twice (one scheduling and dispatch build spent a large share of its total scope on exactly that connector).

How much of your history has to move. Starting clean is quick. Moving years of records takes real weeks. Shifting tens of thousands of legacy files into a per-client document archive, and separately reconciling a spreadsheet full of duplicate and hidden rows, is billable work that has to finish before any new feature can be trusted.

How many roles need different permissions. A single-user tool is quick to build and quicker to test. Give it an admin, an office coordinator and a technician, each seeing only what they are allowed to see, and both the design and the testing grow. A three-role permission model is the shape most shops this size land on, and a serious build runs automated tests that read the actual HTML a technician’s phone renders, checking for the literal absence of dollar signs and pricing data, because a template that hides the price is a weaker promise than a test that fails when the price shows up.

How much a mistake would cost if the system gets it wrong. Money math, invoice numbering and overtime rules get hammered harder in testing than anything else, since a bug there costs real dollars. A pricing and overtime engine built against a provincial overtime rule warrants a table-driven test suite with dozens of cases before it goes near a live invoice. Testing at that depth takes time, and time is the biggest input into any quote.

Whether it needs to run unattended, on a schedule. Recurring and contract billing, flag-only GPS auditing, scheduled reports: anything that has to keep working correctly with nobody watching needs more design up front than a tool somebody operates by hand each time. Recurring-contract billing is common enough that it usually gets scoped and built as its own phase for that reason.

What Blows Up a Budget

Messy existing data. This is the most common reason a budget runs past what was first discussed. Duplicate records, inconsistent numbering, rows that get counted twice: all of it has to be found and fixed before anything new can be trusted to run on top of it. An independent, adversarial re-derivation of every figure in an old receivables workbook is the clearest example of what that cleanup looks like in practice.

Discovery done without the person who’ll use the system. A workflow described from the office looks different from the same workflow described by the technician standing in a client’s mechanical room. Requirements written in the client’s own day-to-day language about the job, rather than reconstructed after the fact by whoever’s building it, are what a build should follow. Skip the step and guess at the workflow, and the design gets torn up mid-build, which costs more than getting it right the first time.

Scope that changes mid-build. Every build should start from a specific, written scope. Adding a system, a role or a compliance rule after work has started costs money, because it can reach back into decisions already made elsewhere in the system. Nailing the scope down before anyone starts is the cheapest move an owner has for controlling the final bill.

The Two Shapes a Build Takes

Some of this work fits inside a single fixed-scope build, agreed up front, quoted once, delivered as one thing. Most straightforward replacements of a paper process, a group chat or an Excel template land in that shape.

Larger systems get built in phases. A core flow ships and goes into daily use first, then a later phase (recurring billing, a legacy-data migration, a new integration) is scoped and quoted separately once the core system is proven. Most of the trades builds behind this site used a mix of the two shapes over their lifetime.

How to Control the Cost

Write down exactly which systems need to talk to each other and what information moves between them, before the first conversation about price. Vague scope is the surest route to paying for redesign later.

If you know your existing data is a mess, say so up front. Cleaning up what you can yourself is cheaper than paying for that cleanup on the clock, and far cheaper than finding the mess halfway through a build.

Decide early whether you need this in two weeks or two months. A compressed timeline costs more because it buys more concentrated effort per week. The work itself doesn’t change.

Expect ongoing care to be a separate cost after launch. A fixed build price won’t absorb it forever. Most of the builds behind this site included a support arrangement after the core system went live, billed separately and by agreement.

A custom build gets scoped against the specific mess it replaces, which is why this page lists cost drivers. If you want a number, our pricing page explains what that conversation looks like and why it starts with a scoping discussion.