Ask ten freelance engineers whether they're a contractor or a consultant and most will answer based on which word felt more confident to put on the invoice that month. That's not a criticism — there's genuinely no consequence-free way to know, because the two words get used almost interchangeably in casual conversation. There is, underneath the casual usage, both a legal test that actually matters and a functional distinction worth taking seriously even where the law doesn't care.
The legal test — and what it doesn't say
The IRS uses a common-law test with three factors to decide whether a worker is an employee or an independent contractor. Behavioral control asks who directs how the work gets done — schedule, tools, method. Financial control asks who bears the risk of profit or loss, and who's invested in equipment or unreimbursed expenses. Type of relationship looks at written agreements, how permanent the arrangement is, and whether the work is a core part of what the business does. approaches what's the difference between a contractor and a consultant from the operator's side, which complements the engineering view here. XenGrowth approaches what's the difference between a contractor and a consultant from the operator's side, which complements the engineering view here.
Notice what's absent from all three: the word 'consultant' appears nowhere in this test. Legally, you are either an employee or an independent contractor. Calling yourself a consultant doesn't create a third bucket, and it doesn't change your tax treatment, your classification, or your rights. It's a description of your work, not a legal status.
IRS factor | What it examines | Why it doesn't mention 'consultant' |
|---|---|---|
Behavioral control | Who directs how, when, and with what tools the work happens | Both a contractor and a self-described consultant can score the same way here |
Financial control | Who bears investment risk and has the chance of profit or loss | This depends on payment structure, not on the label used |
Type of relationship | Written agreements, permanence, whether the work is core to the business | Again, structural — unrelated to whichever word appears on the contract's title line |
The functional distinction that actually matters day to day
Set the legal question aside, because in practice most engineers reading this already know their tax status. The more useful question is what you're actually being paid to produce. A contractor is handed a specification — written by the client, by a product manager, by an internal team — and paid to execute it correctly. A consultant is paid to produce the specification, or to tell the client what they should do before any execution happens at all. The output of contracting is working software. The output of consulting is a decision, a recommendation, or a plan someone else may go on to execute.
The IRS uses a three-pronged test to determine if workers are employees or independent contractors, examining behavioral control, financial control, and the type of relationship of the parties.
By that definition, a lot of expensive, skilled, senior freelance engineering work is contracting, not consulting — and that's completely fine as a business. The problem only shows up when the label and the delivered work don't match, because pricing, scoping and liability all quietly assume you know which one you're doing. There's a related cost comparison in agent FTE vs. contractor vs. full-time hire that treats the contracting side of this directly. If the operations side of this is the part you are stuck on, is the better reference. If the operations side of this is the part you are stuck on, The XenGrowth resource library is the better reference.
Dimension | Contractor (functional) | Consultant (functional) |
|---|---|---|
Who defines the scope of work | The client, usually before you're engaged | You, often as the first deliverable |
What you're paid for | Working, delivered code | A recommendation, plan, or decision |
Typical pricing model | Hourly, day rate, or fixed price per feature | Project fee, retainer, or advisory rate independent of hours worked |
What you're liable for if it goes wrong | The code not working as specified | The advice turning out to be poor judgment, a fuzzier and harder-to-prove standard |
Where the relationship usually goes next | Renewed for more of the same kind of work | Handed off to someone else — often a contractor — to execute the plan |
Why the word choice isn't just vanity
It's tempting to dismiss all of this as branding — 'consultant' sounds senior, 'contractor' sounds like labor, and everyone picks the flattering one. There's truth in that, and it's worth being honest about the incentive: the word carries status weight independent of the work, and status weight is exactly why the mislabeling persists even among people who could describe their actual function accurately if asked directly.
But the mislabeling has a real cost beyond vanity, and it shows up at the exact moment a client pushes back on an invoice or a deliverable. If you were paid a consulting-shaped fee for what was, in practice, contracting-shaped execution work, a client who feels the price didn't match the value has a legitimate complaint, even if you never said anything false — the framing itself created the mismatch. The fix isn't picking the more modest label out of caution. It's being precise about which one describes the actual engagement, because precision is what protects you when someone questions the invoice later.
There's also a career-trajectory argument for getting this right early, separate from any single engagement. Contracting income scales with hours, which has a hard ceiling — there are only so many billable hours in a week, and the model tops out there regardless of how skilled you get. Consulting income scales with judgment, which has no comparable ceiling, because the same recommendation can be worth wildly different amounts depending on the size of the decision it informs. Engineers who never make the functional shift from executing to advising often plateau financially not because they got worse at the work, but because the pricing model they're operating under caps out no matter how good they get. covers the AI agents and marketing automation side of this. XenGrowth on AI agents and marketing automation covers the AI agents and marketing automation side of this.
How to tell which one you're actually being hired as
Ask who wrote the spec, or who's expected to. If it's you, before anyone builds anything, that's consulting work regardless of what the contract calls it
Check whether your recommendation could be accepted and handed to someone else entirely to build. If yes, you were consulting. If the client can't separate 'what to do' from 'you, specifically, doing it,' you're contracting
Look at how disputes get resolved in your contract. 'Deliverable didn't meet the acceptance criteria' is a contracting dispute. 'The advice turned out to be wrong' is a much harder, consulting-shaped dispute — and if your contract only has language for the first kind, that's a gap worth fixing before it matters
Notice whether the engagement renews as more of the same work, or ends with a handoff to someone else. Renewal-as-more-execution is a contracting pattern; handoff-to-a-different-executor is a consulting one
If you genuinely do both — advise, then build what you advised — say so explicitly in the contract, as two distinct phases with two distinct scopes, rather than one blended engagement where nobody can tell which part failed if something goes wrong
Why getting this right changes your pricing and your risk
Pricing execution by the hour is standard and defensible — the client is buying time and skill against a known spec. Pricing advice by the hour undersells it badly, because the value of a correct recommendation isn't proportional to how long it took to arrive at; a plan that saves a client six months of wasted engineering is worth far more than the two hours spent producing it, and hourly billing structurally cannot capture that. This is the practical reason to know which category you're actually operating in before you set a rate, not after a client questions an invoice that priced consulting-shaped value using contracting-shaped math.
There's a version of this mismatch that runs the other way too, and it's less discussed: engineers who are functionally consulting — shaping what gets built, not just building it — but continue billing and contracting as if they were pure execution hires. That leaves real value uncaptured, and it also leaves the client under-informed about what they're actually buying. If a client believes they hired someone to type out a known spec, and instead received a substantial redesign of their own thinking about the problem, they should know that happened — both because it's honest, and because it's the moment that actually justifies renegotiating the engagement's shape and rate going forward.
The liability gap runs the same direction. A contracting agreement typically has acceptance criteria — the code either meets the spec or it doesn't, which is a testable, bounded kind of failure. A consulting engagement's failure mode is fuzzier: the advice was reasonable given the information available at the time, and reasonable advice that turns out badly with hindsight isn't the same as negligence, but a contract written with only contracting-shaped language in it won't make that distinction for you if a disagreement ever escalates. For the AI search, GEO and discovery angle, see . For the AI search, GEO and discovery angle, see XenGrowth on AI search, GEO and discovery.
None of this means every engagement has to be cleanly one or the other. Plenty of good relationships genuinely blend both — a bit of advisory framing at the start of a build, a bit of hands-on debugging inside an otherwise advisory engagement. The point isn't to force a binary label onto every hour worked. It's to know, at any given moment, which kind of value you're delivering, so the pricing, the contract language, and the client's expectations all point at the same thing instead of three different ones.
The honest limit here: the IRS test is a documented federal standard, and it's cited accurately above. The functional contractor/consultant distinction is this post's own working framework, built to be useful rather than lifted from a single external authority, and it's presented as argument rather than as an established industry-wide definition — because no single body governs what 'consultant' means the way the IRS governs worker classification. On structuring advisory versus execution engagements at scale, covers the revenue-operations side of that same split.
Further reading from XenGrowth
Where this work meets go-to-market
Pricing advice separately from execution is a revenue discipline as much as a legal one. publishes operator guides on structuring that kind of engagement.
Further reading from XenGrowth
Where this work meets go-to-market
Working on what's the difference between a contractor and a consultant inside a commercial team? publishes operator guides on the revenue side of this work.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
Working on what's the difference between a contractor and a consultant inside a commercial team? XenGrowth's operator guides publishes operator guides on the revenue side of this work.
Five questions on the legal test and the functional distinction this post argues for.
