AI consultant or software developer?

If you know exactly what you want built, hire a developer. If you know something is wrong and not what to do about it, a developer will build you whatever you ask for and it may well be the wrong thing.

That is the entire distinction, and it is worth a few hundred words because the failure mode is expensive in both directions.

What each one is actually for

A developer's job is construction. You bring a specification, they turn it into working software, and their skill is in doing that reliably, maintainably, and faster than you could. A good one will push back on a bad spec, but pushing back is not their function and they are not being paid to audit your business.

A consultant's job is diagnosis and sequencing. Where does your operation leak, which leak is worth fixing first, what should it cost, should you build it or buy something off the shelf. The output is a decision, not a system.

Different products. The confusion happens because in this field the same firm often sells both, ours included.

The two ways companies get it wrong

Hiring a developer with no diagnosis. You end up with a well-built thing that solves a problem you had not ranked. The classic version is automating the process the loudest person complained about, which is frequently a low-frequency annoyance rather than a real cost. The code works, the business does not change, and the conclusion drawn is that AI does not work here.

Hiring a consultant when you already know what to build. You pay for a document that tells you what you told them. Real, common, and the honest response from any consultant should be to decline the work. If you can name your top three automations in order with rough values, you do not need a diagnosis. The test is here.

Where the line genuinely blurs

Two things worth knowing.

Most AI work is less code than people expect and more plumbing: reconciling data that lives in three systems with different customer identifiers, deciding what happens on an exception, wiring an output into whatever your team already looks at. That plumbing is where projects succeed or fail, and it needs someone who understands the operation, not only someone who can write software.

And modern development tooling means a competent generalist can now assemble things that would have needed a specialist a few years ago. That is good and it shifts the scarce skill away from construction and toward knowing what to construct.

What a developer cannot tell you

Whether your exception rate makes the process a bad candidate. Whether the team whose work this changes will quietly resist it. Whether buying something existing beats building. What the thing is worth if it works. Which of your five ideas to do first.

None of that is a criticism. It is outside the job.

What a consultant cannot do

Ship. Diagnosis with no execution is a document, and documents do not change how your company runs.

This is the standing weakness of strategy-only firms and the reason so many roadmaps end up in a shared drive. If you engage a consultant, know before you start who builds the recommendation and on what terms. Whether a consultant can implement is the question to settle upfront.

The order that works

Diagnose, then build, and keep the two decisions separate.

The important part is that the diagnosis should not lock you into one builder. A roadmap specific enough for any competent developer to execute is what you want, because it preserves the option to shop the build, and preserving that option is what keeps the advice honest.

That is why we write the roadmap so it stands alone and say plainly that you can take it elsewhere. We also build, and we would like the work, but a recommendation only means something if declining it is easy. How the engagement is structured, and how to design the contract so you are not locked in.