How do I implement AI without getting burned?

Why does hiring for this go wrong so often?

Because the role is filled from a job description that nobody in the company was equipped to write. The requirements get drafted by asking a general-purpose assistant what the role needs, and that assistant has no knowledge of your systems, your processes or what you are actually trying to automate. What comes back is a generic engineering specification that would fit any company, which means it fits none.

The salary is then set by the same logic. The band is copied from ordinary software roles, because that is the nearest comparable the market offers. The result is a listing asking for someone who will replace a meaningful share of a department’s repetitive work, priced as though they were writing routine code.

That mispricing is not a moral point, it is a supply problem. People who can specify, build and then operate these systems are currently scarce and have their pick of work. An offer at a standard engineering band selects from the group that could not get the better offer.

What should we check before we sign anything?

The checks below are in the order that saves the most money. The first two are about your own house and cost nothing to run.

1. Does your existing software let anything in? If your CRM, calendar or line-of-business system has no usable API, no amount of hiring fixes it. This is the single most common hard stop, and it is discovered after the contract is signed far more often than before.
2. Is the work repetitive enough to specify? Something you already do the same way every week can be described precisely. A novel task with no established process cannot, and asking anyone to automate it produces an expensive demonstration rather than a working system.
3. Did they ask what is breaking before proposing what to build? A proposal that names a product in the first conversation is selling the product. The order matters more than the answer.
4. Will they produce a short scoping document before any build commitment? One or two pages describing what they would automate and what it would save. Refusal to do that without a signed contract is the clearest single signal available.
5. Are you buying a system or a demonstration? Ask what happens in month three, who maintains it, and what it costs to keep running. A demonstration has no answer to that question.
6. Have you written the brief yourself? Even badly. A brief written from a process you actually run beats a polished one written by someone who has never seen your work.
7. Have you agreed in advance what counts as working? A number, written down, before the build. Without it, evaluation becomes an argument about impressions.
8. Is the first engagement small enough to walk away from? One project, scoped in weeks. Not a year, not a headcount.
9. Do you know how fast they respond when something breaks? You cannot know this before you start, which is exactly why the first project is a test rather than a bet.
10. Is the commercial structure reversible? Part-time, or a revenue share tied to the outcome, keeps both sides honest while you find out.

Should we hire an employee, a contractor, or a firm?

The honest answer is that most mid-market companies should not hire an employee first, because they cannot yet write the job description that would make the hire succeed. The first engagement is how you learn what the role actually is.

The ordering is deliberate. Each row up the table demands more certainty about what you want, and certainty is the thing you do not yet have.

What does the first project actually look like?

1. Pick the boring oneThe highest-volume repetitive process you already run the same way every week. Not the most exciting candidate, the most repeated one.
2. Write down what working meansOne sentence with a number in it, agreed before anything is built. This is what you will judge against when opinions diverge later.
3. Scope it in weeksSmall enough that walking away costs you weeks rather than a year, and large enough that finishing it proves something.
4. Watch the response time, not the demoThese systems break constantly in the first months and need continual adjustment. How quickly someone answers when it breaks is the service you are buying.
5. Then decide about scaleOnly after one project has run in production do you know whether to give them more work, and whether the role you were about to advertise is the role you actually need.

Can we just ask an AI assistant who to hire?

Treat that ranking as advertising rather than research. Being recommended by an assistant is now something that can be worked on deliberately, the same way search rankings were, and the techniques are spreading. I know this because it is a thing I have done, and the honest consequence is that the more people learn it, the less those recommendations tell you.

A more reliable route is to find the people who teach this work in your market, through workshops, training or courses, and ask them who they would send you to. Someone who teaches a subject has met the practitioners and has a reputation that depends on the referral being good.

Frequently asked questions

Related