How to demo a Claude Code build to a client
To demo a Claude Code build to a client, open a link that is already deployed, load the client's own example data, and walk through one real job from the first click to the finished result. Say what the job is before you start, show the result, and stop. Keep the code, the prompts and Claude itself off the screen. The client hired you to remove a problem. The demo is the moment they see the problem gone.
Everything else in this post is about making that moment reliable. Building with the Claude Code desktop app makes it easy to get something working fast, which is exactly why demos go wrong: the build works on your machine, in your session, with your test data, and then falls over in front of someone else. The fix is a short preparation routine, a fixed structure, and a plan for when something breaks.
Why showing the code loses the room
Showing the code feels like proof of work. To a non-technical client it is noise, and worse, it hands them a reason to start asking questions about things that do not matter to them: which framework, why that database, whether it is "real" code. Every minute spent there is a minute not spent on whether their business problem is solved.
The same goes for showing Claude Code working live. Watching an agent write files is interesting to builders. For a client it raises the question "so why am I paying you?" The answer is perfectly good, because the value is in knowing what to build, how to scope it, and how to check it, but a demo is a bad place to argue it. How to sell AI to non-technical clients covers how to frame that value in the conversation where it belongs.
The rule I use: the client sees their own world, working. Their data, their words, their workflow. If a screen would make sense to a stranger but not to them, it does not belong in the demo.
The prep routine the day before
- Deploy it. A demo runs on a real link, not localhost. If you have not deployed this build yet, how to deploy an app with Claude Code is the walkthrough. A live link also lets the client open it themselves afterwards.
- Load their data. Use the client's own example records, names and wording, with their permission. A demo with "Test User 1" asks them to imagine; a demo with their real product list does not.
- Pick one job. Decide the single path you will show, the thing the client does most often or complains about most. One path done well beats a tour of every screen.
- Run that path end to end, twice, the morning of the call. Once to check it works, once to time it. Then reset the data to a clean starting state so the demo does not begin with your leftover tests.
- Prepare the failure fallback. Record a short screen capture of the working path as a backup, and have it ready in another tab. Connections drop and services time out; the backup keeps the call alive.
- Check the account state. Make sure any logins, API keys and third-party services the path touches are active and not close to a limit. Review Claude Code output before you ship has the pre-flight list I run before anything goes in front of a client.
The demo structure: outcome, path, result, ask
Run every demo in the same four beats. It keeps you calm, and it keeps the client oriented.
- Outcome (one sentence, before you share your screen). "Last time you told me that taking bookings by email costs you an evening each week. I am going to show you a booking request arriving and being confirmed without you touching it." You restate their problem in their words so the demo has a yardstick.
- Path (the live walkthrough). Narrate what the person using it does, not what the software does. "A customer picks a time, gets a confirmation, you get a notification." Go slowly and stop talking while something loads.
- Result (the payoff moment). Show where the outcome lands: the confirmation, the report, the spreadsheet row, the message sent. Then be quiet for a few seconds. Let them react.
- Ask (the close). Tie the demo to the next step in the agreement: "If this matches what we scoped, the next step is signing off this milestone so I can move on to the second part." Name the date or the action. How to close an AI client over email is useful for the follow-up message that goes out the same day.
What to do when something breaks on screen
Something will break eventually. How you handle it matters more than the break. Say what happened in plain words, once, without panic: "That did not load. I am going to reload and try that step again." If the second try fails, switch to the recorded backup and keep going: "Let me show you the recording of that path, and I will fix the live version and send you the link today." Then actually do it.
Do not debug live in front of a client. Do not open the terminal, do not start talking to Claude about the error while they watch, and do not explain the technical cause at length. Note the issue, move to the next part of the demo, and fix it after. Clients forgive a break that is handled calmly and followed by a quick fix. They do not forgive a long silent debugging session or a vague excuse. If the break reveals a real defect, how to debug with Claude Code is the process for finding it after the call.
Handling feedback during and after the demo
Clients almost always ask for something new during a demo, usually starting with "could it also...". Do not agree on the spot and do not refuse. Write it down visibly and say: "Good idea, I will note that and tell you what it would involve." Then sort every request into one of two buckets afterwards: part of what was agreed (fix it as part of the current milestone) or new (quote it separately). How to handle scope creep on client projects has the wording, and how many revisions to include in an AI project explains how to keep feedback rounds finite.
Within the same day, send a short written recap: what you showed, what they confirmed, what they asked to change, and the next step with a date. That message is also your record that the milestone was shown and accepted. If you plan to hand the finished build over, how to hand off a Claude Code project is the step after sign-off.
Common demo mistakes
- Demoing from localhost or a laptop-only setup. If it only works on your machine, it is not ready to show.
- Using fake data. It forces the client to translate your demo into their reality, and they usually do not.
- Showing every feature. A tour makes the build feel generic. One real job makes it feel like theirs.
- Talking while the thing loads. Silence feels long to you and normal to them. Let it finish.
- Explaining how it was built. Unless they ask, skip it. If they do ask, give one sentence and move back to the result.
- Ending without an ask. The last minute of the call should name the next step and the date.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
How long should a client demo of an AI build be?
Keep the live walkthrough short, under fifteen minutes, with the rest of the call for questions and the next step. One real job done start to finish lands better than a long tour of every screen.
Should I show the client the code or Claude Code during a demo?
No, unless they ask. Clients are judging whether their problem is solved, not how it was built. Showing code or an agent working invites questions that do not help the decision. Keep the screen on their world: their data, their workflow, the result.
Should I do a live demo or send a recorded video?
Do the live demo on a deployed link, and keep a short recording of the working path as a backup in case something fails. Send the recording afterwards along with a written recap so the client can review it and share it with others.
What if the demo breaks in front of the client?
Say plainly what happened, try the step once more, and if it fails switch to the recorded backup and continue. Do not debug live. Fix it after the call and send the working link the same day.
How do I end a client demo so it leads to a sign-off?
Tie it to the next step in the agreement and name a date. For example, ask them to sign off the milestone so you can start the next part. Follow up the same day in writing with what was shown, what they confirmed and what they asked to change.
Last reviewed by David Iya on October 2, 2026
