The short version
Describe the problem, not the solution. Insist on a credential you can check yourself. Pay for discovery separately from the build. Agree up front who owns the prompts and the code. And be more suspicious of a fixed quote given without questions than of one that arrives a week later with caveats.
What a Claude consultant actually does
Very little of the work is writing prompts. A competent engagement is mostly unglamorous: working out which part of a process is actually costing you money, getting Claude reliable access to the data it needs, deciding where a human has to approve something, and building a way to tell whether the output is good enough to trust before anyone relies on it.
This matters because Anthropic now ships ready-made agents and workflows for common tasks — invoice tracking, month-end close, KYC screening and others. If your problem is one of those, the model and the template already exist. What does not exist is the connection to your systems, the permission boundaries appropriate to your risk appetite, and the evidence that it works on your data. Anthropic’s own documentation tells firms to adapt these templates to their own conventions, risk policies and approval flows. That adaptation is the job you are hiring for.
How do I tell a real practitioner from someone who watched a course?
Ask for a credential and then verify it yourself rather than accepting a screenshot. Anthropic issues four Claude certifications through proctored exams and badges them on Credly, and every badge has a public verification page showing the holder’s name, the exact credential and the dates it is valid for. A genuine holder can hand you that link in seconds. Certifications also expire after twelve months, so check the date rather than the badge.
A credential proves someone passed an exam. It does not prove they have delivered anything, which is why the second question matters more: ask what they have put into production, what broke, and what they changed as a result. Anyone who has actually shipped one of these has a good answer about something that went wrong. The people who have only studied tend to describe capabilities rather than incidents.
What does it cost?
Enough that you should scope it before you commit, and not so much that the first conversation should be about price. Rates vary widely by market and seniority, and any figure quoted as a universal benchmark is guesswork dressed as data.
What you can control is the shape. Pay separately for a short discovery — a defined piece of work producing a written recommendation, a scope and a price — and treat that document as the deliverable. If the recommendation is “don’t build this”, you have bought the cheapest possible version of that answer. If it is a proposal, you now have something to compare against other proposals rather than comparing day rates, which tell you almost nothing.
Describe the problem, not the technology
The single most common mistake is arriving with a solution already chosen. “We want a chatbot” is a specification of a shape, not of a problem, and it forecloses the answer before anyone has looked at the work.
A brief that gets useful responses says:
- What happens today, in concrete terms — who does it, how often, how long it takes.
- What it costs you, in hours or errors or delay. This is what sizes the engagement.
- Where the data lives, including the awkward parts — the system with no API, the PDFs from suppliers, the spreadsheet three people maintain.
- What you have already tried, and why it did not hold.
- What “working” would mean — the threshold at which you would trust it.
- Any constraint that is non-negotiable — data residency, regulatory approval, a system you cannot touch.
That last one saves the most time. A constraint discovered in week three usually invalidates the plan.
What should I ask before committing?
Six questions, and the manner of the answers tells you as much as the content:
- What would make you tell us not to do this? Someone who cannot think of anything is selling.
- How will we know it works? You want a measurable threshold, not a demo.
- What happens when it gets something wrong? Every deployment needs an answer, and “it won’t” is not one.
- Who owns the prompts, the configuration and the code afterwards? Settle it in writing before work starts, not at handover.
- What access do you need, and can it be narrower? A good practitioner argues their own access down.
- What does this cost to run, not just to build? Token spend, review time, and whoever maintains it when the model changes.
Freelancer, agency, or certified individual?
Large consultancies have a floor on engagement size that puts most small and mid-sized problems out of reach — not because they cannot do the work, but because a £15,000 project does not fit their model. If your problem is that size, you are looking at an independent practitioner or a small specialist firm.
The trade is straightforward. An individual gives you the person who does the work and usually moves faster. A small firm gives you cover when that person is ill and more than one pair of hands for delivery. Neither is safer by default. What makes either safe is a verifiable credential, evidence of delivered work, and a scope small enough that being wrong is survivable.
The order that works
- Write the problem down, in the shape above.
- Talk to more than one practitioner. Different people will read the same problem differently, and that divergence is information.
- Verify every credential yourself.
- Buy discovery. Read the recommendation.
- Agree ownership, access and the definition of “working” in writing.
- Then build — the smallest version that proves the point.
The whole sequence is designed to make the expensive mistake — building the wrong thing well — as hard as possible to make.
How do I check a Claude certification is genuine?
Ask for the verification link rather than a screenshot. Anthropic badges these credentials on Credly, and each badge has a public page showing the holder’s name, the exact credential, and the dates it runs between. Anyone who holds one can send that link in seconds.
Check three things on it: that the name matches the person you are talking to, that the credential is the one they claimed, and that the expiry date has not passed. Certifications run for twelve months, so a badge earned eighteen months ago is a badge, not a current credential.
What are the warning signs?
- A fixed price before any questions. Nobody can scope your integration without seeing it.
- No risks named anywhere in the proposal. Every real project has three or four.
- Requesting broad production access early "to move faster". Discovery works on a redacted sample.
- Capabilities rather than incidents. Ask what broke last time; someone who has shipped has an answer.
- Vagueness about who owns the code and prompts. This gets worse at handover, not better.
- A screenshot instead of a verification link. The link takes ten seconds to produce.
How long should this take?
Discovery in one to three weeks, and a first useful deployment measured in weeks rather than quarters for most small and mid-sized problems. If a proposal describes a six-month programme before anything is in anyone’s hands, ask what could be delivered in six weeks instead — the answer tells you whether the scope is genuinely large or simply unscoped.
Add a parallel run to whatever timeline you agree. Nothing should change anyone’s workload until the system has produced the same answers as the manual process for a full cycle.