What Does a Custom Automation Build Actually Cost?

Every owner asks the same question: how much will this cost? The honest answer is that it depends on five things, and most of the surprises happen because one of them was glossed over at the start. This page is not a price list. See /pricing for why we don’t publish one. What follows is the actual set of drivers, each grounded in a real, documented Ontario trades engagement rather than a generic checklist.

The Five Cost Drivers

How many systems have to talk to each other. A standalone tool built once, from scratch, with no external dependency, is the cheapest shape a build can take. Cost climbs the moment it has to connect to something the business already runs. An HVAC scheduling and dispatch build had to integrate with QuickBooks Desktop over the Web Connector, using qbXML, with cent-match reconciliation against QuickBooks’ own returned total and a guard against double-invoicing the same work order. That single integration was a substantial share of the project’s total scope, not a checkbox at the end.

How much of your history has to move. A fresh start is fast. Migrating years of records is not. A fire-safety inspection contractor’s rebuild moved roughly 42,000 legacy files into a per-client document archive, and separately had to reconcile a roughly-490-row accounts-receivable spreadsheet with duplicate and hidden rows before a single new invoice could safely go out. That cleanup was real, billable work, done before any new feature could be trusted.

How many roles need different permissions. A single-user tool is simple to build and simple to test. A system with an admin, an office coordinator, and a technician role, each seeing only what they are allowed to see, takes more design and more testing. The fire-safety rebuild used a three-role permission model, and one build in this pattern ran automated tests that scan the actual rendered HTML a technician’s phone shows, checking for the literal absence of dollar signs and pricing data, because “the template doesn’t show it” is not the same guarantee as a test that checks.

How much a mistake would cost if the system gets it wrong. Money math, invoice numbering, and overtime rules get tested harder than everything else, because a bug there costs real dollars, not just an annoyance. The HVAC build’s pricing and overtime engine ran a 20-case table-driven test suite against Ontario’s Employment Standards Act overtime rules before it touched a live invoice. That level of testing takes time, and time is the largest 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 it needs more design up front than a tool a person operates by hand each time. The fire-safety rebuild’s recurring-contract billing was scoped and built as its own phase for exactly this reason.

What Actually Blows Up a Budget

Messy existing data. This is the single most common cause of a budget running over what was first discussed. If the data going into a new system is a mess (duplicate records, inconsistent numbering, rows that shouldn’t be counted twice), that has to be found and fixed before anything new can be trusted to run on top of it. The fire-safety engagement’s accounts-receivable cleanup is the clearest documented example of this: an independent, adversarial re-derivation of every figure in two Excel workbooks, done before the new system went live, not after.

Discovery done without the person who’ll actually 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. The HVAC project’s own requirements came directly from the client’s day-to-day language about the job, not a generic template, and the build reflects that. Skipping this step and guessing at the workflow is how scope gets redesigned mid-build, which costs more than getting it right the first time.

Scope that changes mid-build. Every engagement we’ve documented started with a specific, written scope. Adding a system, a role, or a compliance rule after the build has started is not free, because it can touch decisions already made elsewhere in the system. Locking the scope down before work starts is the single cheapest thing an owner can do to control the final bill.

The Two Shapes a Build Actually Takes

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

Larger systems get built in phases instead: a core flow ships and goes into daily use first, and a later phase (recurring billing, a legacy-data migration, a new integration) is scoped and quoted separately once the core system is proven. Both documented engagements behind this site used a mix of both 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 most reliable way to end up paying for redesign later.

If you know your existing data is a mess, say so up front. It is cheaper for you to clean up what you can yourself than to pay for that cleanup on the clock, and it is far cheaper than discovering the mess mid-build.

Decide up front whether you need this in two weeks or two months. Compressed timelines cost more, because they mean paying for more concentrated effort per week, not because the work itself changes.

Expect ongoing care to be a real, separate cost after launch, not something a fixed build price absorbs forever. Both documented engagements here included support arrangements after the core system went live, billed separately and by agreement, not folded silently into the original number.

The cost of a custom build is scoped against the specific mess it is replacing, which is why this page describes cost drivers instead of a price list. If you want an actual number, /pricing explains what that conversation looks like and why it starts with a scoping discussion rather than a quote.