At some point in evaluating AI, most owners ask the same question: should we just hire someone for this?

It's a reasonable instinct. You hire an estimator instead of contracting one out because estimating is constant, ongoing work. Why would AI be different? The answer is that for most trades and construction businesses, right now, it is different, and the math explains why.

What the in-house role would actually do

Before posting a job listing, work through the year. Month one, this person maps your workflows and figures out where AI fits, the same work an assessment does in a week. Months two and three, they build and implement the first use case, proposal drafting, say. Month four, they're refining it. Then what?

Once the first workflow is live and stable, a full-time AI hire in a 20-person contracting business runs out of net-new work fast. You end up paying a full salary, benefits, and management overhead for someone whose job, after the first quarter, is mostly maintaining one or two systems and waiting for the next problem worth solving.

Run the timeline further and the pattern doesn't improve. Month six, they've implemented documentation automation as a second project. Month nine, scheduling assistance. By month twelve you've built three systems, which is a genuinely good year of work, and now you're paying a specialist's salary to babysit three systems that mostly run themselves, while the next use case worth building might not surface for another two quarters.

The hiring problem you'd actually be solving

Set the cost math aside for a second and look at the hiring itself. Who is this person?

You need someone who understands construction or trades workflows well enough to spot where AI genuinely helps, understands AI implementation well enough to build it without creating a governance mess, and is willing to take a single-employer role in the Okanagan doing work that, once the first few systems are built, has a shrinking scope.

That's a narrow set of people, and it's not a labour pool with much depth in Vernon or Kelowna right now. Post that job and you're likely choosing between a software person with no trades context, who builds something technically sound and practically useless, or a trades person with light AI exposure, who needs a year of ramp-up before moving fast. Either way, you're paying full salary while someone gets up to speed on half the job.

And if that person leaves in eighteen months, which happens, you're not just re-hiring. You're re-hiring for a role narrow enough that the last search was hard, while whatever they built quietly stops getting maintained.

What a consultant engagement actually looks like

Worth being concrete about this, since "consultant" covers a lot of ground and some of it deserves the skepticism trades owners have toward outside advice.

A well-structured engagement runs in phases, not an open-ended retainer with vague deliverables. Discovery comes first: walking the actual workflow, talking to the people who touch it every day, not just the owner's version of how the business runs. That surfaces where the friction actually is, which is often different from where the owner assumed it was.

Build comes next, on the use case with the biggest payoff identified in discovery, with the people who'll use it involved in shaping it rather than being handed a finished system. Governance gets set up alongside the build, not bolted on after, covering who approves what and what data the tool can touch.

Then handoff: training the team, documenting how the workflow runs, and being available for the inevitable questions that come up once real use starts. A good engagement has a defined end, and a defined answer for what happens after it ends, whether that's a maintenance retainer, a trained internal owner, or both.

The math, worked through

Say a 20-person contractor lines up the two options side by side: a full-time in-house hire, salary plus benefits plus the management time to oversee them, against a project-based engagement to build and govern the first two workflows, followed by a lighter retainer for maintenance and the occasional new build. In year one, the project-based route usually costs less, because it's priced against defined deliverables instead of a full year of salary regardless of how much net-new work actually exists.

The gap narrows in year two if the business genuinely keeps generating new AI use cases at a steady pace. It doesn't narrow if the pace slows down after the first wave of obvious wins gets built, which is the more common pattern for a company this size. Running the actual numbers, instead of assuming a full-time role pays for itself because it feels like the more serious option, is the only way to know which pattern your business is in.

None of this is an argument that hiring is always wrong. It's an argument for running the numbers on your specific business instead of defaulting to whichever option feels more permanent or more serious. A contract can be renewed. A salary is much harder to walk back once someone's counting on it.

Where the comparison actually favors a consultant

There's a fourth point that doesn't fit neatly into that list. A consultant has no reason to keep inventing work to justify a position. When the use cases that actually mattered are built and stable, a good consultant tells you that and scales the engagement down. A salaried role doesn't come with that same built-in honesty, not because people are dishonest, but because a job needs enough scope to exist.

"Isn't an outsider a bigger risk with our data?"

This comes up in almost every conversation, and it deserves a real answer instead of a brush-off.

An in-house hire has access to everything, indefinitely, as an employee, which comes with its own risks around turnover and how carefully any one person handles sensitive information over the years. A consultant engagement should run on the opposite principle: scoped access, defined by the work being done, governed by an agreement that spells out what can be touched and what can't, and closed out when the engagement ends.

The real question isn't in-house versus outside. It's whether whoever touches your pricing history, client data, and job records is operating inside clear rules, with accountability attached. That's a governance question either way, and it needs an answer whether the person building your AI workflows is on payroll or under contract.

Questions worth asking before you decide either way

What if we hire someone part-time instead of full-time? That's a reasonable middle ground for some businesses, but it usually just relabels the same problem. A part-time AI hire still needs the combined skill set that's rare in this market, and part-time roles in a specialized field tend to attract people building a portfolio, not people planning to stay.

Won't a consultant just try to sell us more work than we need? That risk is real with a bad consultant, the same way a bad subcontractor pads a change order. It's a reason to ask for a defined scope up front and a clear statement of what happens when the initial build is done, not a reason to default to hiring instead.

Can we start with a consultant and hire in-house later if the workload justifies it? Yes, and that's often the cleanest path. Nothing about starting with an outside engagement locks you out of building an internal team once there's a proven, growing case for one.

Where an in-house hire actually makes sense

The calculation changes at scale. A manufacturing operation running dozens of product lines with continuous documentation, data, and compliance needs has enough ongoing AI-adjacent work to justify a dedicated role. So does a company big enough to be building custom internal tools continuously, not just implementing a handful of defined workflows.

The dividing line isn't company size alone, it's whether the AI work is a project with an end state or a continuous, expanding function. Most trades and construction businesses in the 5-50 employee range are the former, at least for the first several years of adoption.

Here's a useful test: list every AI use case you can currently think of for your business. If that list has a bottom, an end, a point where you'd genuinely run out of high-value projects, you're looking at a project, not a role. If the list keeps growing every time you look at it, because the business itself is complex enough to keep generating new AI-adjacent problems, that's a different conversation.

Growth changes the answer too. A company that's 15 people today but has a real, funded plan to double within three years is a different case than one that's held steady at 15 for a decade. If the AI workload is going to scale with headcount and project volume, it may be worth building internal capability early, even if the first year looks like overkill, because the ramp-up time for a new hire doesn't shrink just because you need them faster later.

What "consultant" actually means in practice

The word covers a wide range of arrangements, and it's worth being specific about which one you're buying. A project engagement has a start and an end: discovery, build, governance, handoff, done. A retainer keeps the same person or team on call for ongoing work, smaller in scope than a project but recurring. Some businesses need one, some need the other, and plenty need a project first, followed by a much lighter retainer once the initial systems are live.

The mistake to avoid is signing a retainer that never converts into anything, just an open-ended monthly fee with no defined deliverables. That's the outside-consultant version of the same problem a stalled in-house hire has: cost that doesn't shrink even as the actual workload does.

A middle path

This isn't all-or-nothing. Bringing in a consultant to handle discovery, build the first workflows, and set up governance, then training an internal person to own maintenance and small iterations, gets you expert sequencing up front without carrying a full-time AI salary before there's enough ongoing work to justify one.

In practice, that internal person is often someone already on staff, an office manager, a project coordinator, someone who already understands how the business runs. They don't need to be able to build a system from scratch. They need to be able to keep one running, notice when something's off, and know when a problem is big enough to bring the consultant back in for.

How to actually decide

Start by finding out what's actually there to build. If the answer is one or two high-leverage workflows, a consultant engagement gets it done faster and cheaper than a hiring process, onboarding, and a learning curve. If the answer is a genuinely continuous, expanding need, that's a different conversation, and worth having with real numbers instead of a guess.

Give yourself a real timeline to answer it, not an open-ended "we'll figure it out eventually." A week is usually enough to map the current workflows and get a straight answer on how much genuine, ongoing AI work actually exists in the business right now, versus how much is one good year of implementation followed by light maintenance.

Most owners I talk to haven't actually run this exercise. They've felt the pull toward hiring because AI feels important enough to deserve a dedicated person, which is an understandable instinct and also not the same thing as evidence that the workload supports one.

The assessment is the fastest way to find out which situation you're actually in.

Take the free assessment →