AI for consultancies: show the client a working prototype on day one

The most useful thing AI has done for my consulting work is let me build the thing a client is arguing about and put it in front of them, often within a day. That changes the conversation more than any deck I’ve ever written, and I think it’s where an established consultancy can still win.

Most of what you find on AI for consultancies is a list of copilots: summarise the interview notes, draft the slides, search the knowledge base. That’s all fine. The other line I keep seeing is that trust is what wins, and it usually stops there. I agree with the trust part. The method I’ve used is showing people working software early, and being straight with them about what the AI can’t do.

A one-day proof of concept changed the client conversation

I came into some conversational assistant work on one engagement, and the approach at the time was trying to make it deterministic. You cannot make something non-deterministic deterministic. It just creates a bad experience.

I drew them an architecture that was basically function calling, which I’d taken from the way Cursor worked at the time. You’re just two functions. It’s really simple. Then the AI built me a proof of concept in a day: a working function-calling thing, with all of the calls faked out to JSON files. I showed them and said, this is the experience you want. And all of a sudden they said yes, this is the experience we want. They re-formed the team around it and went on to build it properly and release it.

An architecture diagram would have been one more opinion in the room. A working thing with fake data behind it was something people could actually use, and that’s what moved it. For a consultancy, that kind of prototype is now cheap enough to build as part of the conversation, not as a phase in a statement of work. If you want the next step after that, turning it into a pilot you can measure, I’ve written that up in shipping LLM pilots in days.

Test whole architectures against each other

The same goes for arguments about architecture. One of the big things we did at realestate.com.au was split the front end and back end and put queues in the middle. That rebuild took months and months and dragged into two years. On my own property portal this year I did that in a weekend. There are nuances, and it’s not quite the same thing. But you can A/B test whole architectures in a way you couldn’t before.

For years everyone said this is a better architecture, and nobody could prove it, because there was no control group. Now you can build both, run them at the same time and say: actually, the one that’s kept together is better, and the AI does a better job coding it. That’s a deliverable a consultancy couldn’t offer before. Instead of a recommendation backed by experience, you can hand a client two working versions and the evidence for picking one.

The best way I’ve found to calibrate this is to spend your Claude Code rebuilding something you know really, really well. Then you know: when I built this in 2015 it took this long, and we went through this process. You find the current limits, and you can talk about them honestly. The limits move, right? Being able to say what’s changed and when is a big part of being useful to a client.

Clients who think they don’t need you now

The flip side of it being this fast is the client who’s found Claude Code and decides they can do it themselves. “I can do it in such a short time now.” Yes, you can build some stuff. But you’re not an engineer, and you’re going to drive it off a cliff. It’s only a matter of time until it drops a production database, and I’m not joking. Mine has, because I give it extreme levels of access on my own projects to push it as far as it can go. I have backups, and I’ve lost count of the times I’ve been glad of those layers of protection. That protection is engineering, and it’s the part a client doesn’t see when they’re watching the agent type.

I’d rather tell a client that plainly than oversell. Being honest about what the AI can’t do is part of the trust, and it’s the part the vendor pitch leaves out.

When a client doesn’t want to hear it, get good at firing customers. There will always be other customers. You say: look, we’re not a good match, and if you want a referral to somebody who might be, I’ll help. You never burn bridges, because even if you go different directions, that person might be able to help you five years down the track.

Corporates are behind for real reasons, and that’s the work

When I have this conversation with corporate clients, I describe roughly three groups. There’s a sliver of people who are really pushing. There’s a set of people who aren’t technical and are digging themselves really, really deep holes. And then there’s the corporate world, really far behind, with different problems, because you can’t just let the AI go nuts on something that’s bringing in a billion dollars.

Those barriers aren’t there for no reason. There have been plenty of examples of somebody putting forward a report they didn’t read closely enough, with ridiculous, incorrect things in it, and there was a lawyer who appeared in court with a precedent that didn’t exist. The Thomson Reuters Institute’s 2026 AI in Professional Services report found that 40% of firm respondents had received orders from clients both to use AI on their work and not to use it. In the same report, organisation-wide use of AI went from 22% to 40% in a year, and 15% of organisations have adopted agentic tools. Clients are pulling in both directions at once, and helping them sort out which parts are safe is real consulting work.

The way I frame it for them is to treat the AI like a junior developer. It’s much more capable than a junior, but the old adage holds: if the junior breaks production, it’s not the junior’s fault, it’s a team system problem. When I was helping one client move services onto newer versions of Spring Boot, the upgrades would pass on the developer’s machine and then break in the test environment. Whose fault is that? Not the AI’s. There are differences between dev, staging and production, and the build isn’t a full picture of whether it works. All of a sudden you’re being punished for all the bad behaviours you’ve tolerated. Closing those gaps, so the AI can be trusted with more, is the engagement. I’ve written about the gates I use for that in how I let coding agents merge to production.

Smaller clients are a different conversation. A lot of consultants are using things like n8n to automate in a GUI-friendly way. From an enterprise perspective I’ve argued against n8n and the no-code agent builders, because not having it in code is a problem and not having the DevOps around it is a problem. From a small-business perspective I don’t see that problem. They’re not going to be rigorous with their DevOps anyway, and giving them that kind of automation is a real opportunity for consultants.

The effort moat is going

I keep telling CIOs and CTOs to be really aware that they’re losing a moat, and it applies to consultancies just as much. Previously you had some protection from the little upstart, because a lot of effort had gone into building what you had and you already had the customers. Say the effort is now 5% of what it was. And say the AI can do not just the building, but a bunch of the automation and processes you’d have needed a human for, and the outreach as well. The upstart becomes much, much more achievable. It’s the innovator’s dilemma on steroids.

For a services firm, the barrier to entry used to be employees, and that’s disappearing. I can write implementations alone now that would have taken 10 people, and with AI I can do marketing and sales, which have never been my strong point. There’ll be a lot more smaller companies, and some of them will be pitching to your clients.

What an established firm still has is the relationship and knowing the domain. I knew roughly how long that REA rebuild took, which is what made the weekend version mean something. I knew what that assistant should feel like because I’d seen what function calling was doing in Cursor. That’s what makes a one-day prototype land with a client, and it’s why I’d rather spend the day building the thing and showing it than writing the proposal for it.

If you want a second pair of eyes on where AI fits in your own firm’s delivery, that’s what the advisory retainer is for.