Prompt Claude to build something a client can click
Turn an idea into a working demo with Claude: what to decide first, real prompts to copy, and how to steer it one screen at a time.
On this page
By Kaz Kato · Published 12 October 2026 · Updated 12 October 2026
Describe the client, the moment that matters to them and the screens that show it, and Claude builds a demo you can click. Start with one prompt that says who it is for and what they should see. Ask for sample data from the start. Then improve it one screen at a time, in plain words.
This is the first of eight chapters. It gets you from an idea to a working demo. Chapter two makes it look real on sample data, and chapter three has the checks to run before anyone sees it. If you have a demo already, skip to deploying it.
What should the demo show?
Show the one moment your client cares about most, working. Not every feature: the screen where their problem is solved, and the two or three screens that lead to it. A demo that does one thing well, on data that looks like theirs, beats a broad one that looks like a template.
Before you write a word to Claude, decide four things:
- Who it is for. The person who will open the link: their job, and what they check every week.
- The moment that matters. The point in their week where your idea changes something. “Monday morning, when the partners check what came in and which fees to chase” is a moment. “Cash-flow management” is not.
- The screens. Three to five. The one that shows the moment, and the ones a viewer passes through on the way.
- The device. Will they open it at a desk or on a phone? Build for that one first.
The first prompt
Put all four into the first message. Claude does its best work when it knows who the demo is for, so say that before you say what to build. Here is a first prompt for the demo you will see throughout this guide, Ledgerline, a cash-flow dashboard for a small accountancy practice:
Build me an interactive prototype called Ledgerline: a cash-flow dashboard
I can show a prospect, a small accountancy practice.
Who it's for: the partners, who check the practice's cash every Monday.
The moment that matters: seeing what came in, what went out and which
fees to chase, before the week gets away from them.
Make it a small web app with four screens:
1. Overview: cash in and out this month, what is left, and the overdue
fees to chase.
2. Invoices: every fee invoice, with the late ones flagged by how late.
3. A client's page: what they pay the practice, their own bank feed,
and this quarter's work.
4. Forecast: the next 13 weeks from fees, payroll and the VAT calendar,
with the lowest week named.
Use invented sample data throughout, in pounds, with believable UK
business names. No real people or companies. Put a small "Sample data"
label in the footer of every screen.
Keep it calm and professional: plenty of white space, one accent colour,
readable on a laptop. Plain HTML, CSS and JavaScript with no build step,
and index.html at the root.The last line matters if you will send it from a chat. The connector deploys a static demo, with index.html at its root and no build step, straight from the conversation (chapter four has the limits).
Steer it one screen at a time
The first version is a draft. Look at it the way your client will, then ask for one change at a time. Say what is wrong, and what good would look like. These are the kind of follow-ups that move a demo on:
On the overview, the overdue fees should be the first thing the eye
lands on. Put them beside the month's cash, with the total in large type.The invoices table is too dense. Put the late invoices at the top, say
how many days late each one is, and mark them in the accent colour.Make every screen work on a phone too: tables become cards, and the
navigation folds into a menu.Link each client on the invoices list to their own page, and give every
page a way back to the overview.A few habits help:
- One change per message. Two changes in one message are harder to judge, and harder to undo.
- Name the screen. “On the forecast” is clearer than “on the chart”.
- Ask what changed. Claude will tell you, and you will spot a change you did not want.
- Go back when it goes wrong. Ask Claude to return to the version before, rather than fixing a fix.
Where should you build it?
Build it in a chat with Claude when the demo is a handful of pages Claude can hold in the conversation. Use Claude Code when the demo lives in a folder on your machine, needs a build step or has its own server. Both end in the same place: a private room on Roomi, with a link for each person.
| A chat, on claude.ai or in the Claude app | Claude Code, in a folder | |
|---|---|---|
| Best for | A static demo of a few pages | A project with a build, or a server of its own |
| How it reaches Roomi | The connector, from the chat | The roomi CLI, from the folder |
| What you install | Nothing | Node 24 and the CLI |
| A demo with a server | No | Yes, as a container demo on Pro and above |
Either way, the next step is the same: make it look like your client’s world.
Before you move on
- Name the client, the moment that matters and three to five screens
- Ask for invented sample data in the very first prompt
- Ask for plain HTML, CSS and JavaScript with index.html at the root, if it will go out from a chat
- Change one thing per message, and say what good looks like
Questions people ask
Do I need to know how to code?
No. You describe what you want in plain words and Claude writes the code. You look at what it built, say what to change, and ask again. Knowing a little HTML helps you ask precisely, but you do not need it.
Can Claude build an app with a real database behind it?
It can, but a demo rarely needs one. A static demo on sample data opens at once and holds nothing private. If yours needs a server, it goes out from Claude Code as a container demo, on Pro and above.
About the author
Kaz Kato, Co-founder & CTO, Roomi. Kaz co-founded Roomi with Tesh, whom he has built with since 2017: two startups that failed, one venture studio that didn’t, and an exit.