I built a prototype with AI. How do I make it real?

You built it with Claude, Lovable, Bolt or v0. Make it real for a client first, then decide whether to harden it, rebuild it or drop it.

On this page

By Kaz Kato · Published 12 October 2026 · Updated 12 October 2026

Make it real for the people who would pay for it before you make it real as a product. Put the prototype live on mock data, send each of them their own link, and see who uses it, who comes back and who asks for more. Then decide whether to harden it, rebuild it, or drop it.

This guide is for the fork in the road. It covers what “real” can mean and the routes open to you. Then how to tell whether it is worth more work, and what changes once real customers arrive. The how-to guides for v0, Bolt, Replit, Cursor and Claude cover the steps for each tool. The best ways to share an app built with AI compares them. Prototyping shows the loop from the other side.

What does “make it real” mean for a prototype?

It means one of three things. Real to a client: seen, used and wanted by the people you would sell it to. Real as a product: real users, real data and real security. Real as a business: someone pays. Start with the first, because it tells you whether the other two are worth doing.

The order matters because each step costs more than the one before. Showing a working prototype is the smallest. Hardening it for real data is far bigger, and often needs a developer. A business takes everything else. If the first step says nobody wants it, the other two are money you keep. Prototype vs MVP vs proof of concept sets out what each stage asks of the thing.

What are your options once it works?

Five routes, and they answer different questions. Publishing from the builder gets it online. A call or a recording explains it. A room shows it to named people and tells you what each did. Production hosting runs it for real users. A developer rebuilds it to last. Pick by what you need to learn next.

Route What it gets you What it needs from you What you learn Fits when
Publish from the builder (Lovable, Bolt, v0, Replit) A public address, or one for invited people A click; often a paid plan to keep it private Traffic in total, at best A public page anyone may see
A screen share or a recording You drive; they watch A call in their diary, or a video What they say You need to explain it as you go
A room on Roomi (ours) The working app, a guided tour, a link for each person Mock data, and a static build or a Dockerfile Each person’s visits, time on each screen, tour and answers You need to know who wants it
Production hosting (Vercel, Netlify and others) A real app for real users Real security, and a plan that allows commercial use Traffic across the whole site People have already said yes
Hand it to a developer A rebuilt product A budget and a brief Nothing until it ships It is proven, and needs to last

We make Roomi, so weigh that. The builders’ own publishing is fine for a launch page. On Lovable’s Free and Pro plans, a published app is open to anyone with its address by default; “Invite only” limits it to people you add, who must log in. Bolt publishes a project free at a public bolt.host address. A private site, open only to your team and people you invite, needs a paid plan. A published Replit app runs on Replit’s cloud, where everyone can use it. Controlling who can see it is available only to Pro and Enterprise members.

What none of them tells you is whether the one person you sent it to opened it. Lovable’s analytics measures overall traffic, not individual people, and does not follow a visitor from one visit to the next. Vercel’s Web Analytics tells visitors apart by a hash that resets every day, without cookies. It reports pages, referrers, countries, operating systems and browsers across all visitors.

Why show it before you rebuild it

Kaz’s view. I would rather hear no from a handful of people who matter than from a launch nobody came to. A prototype that works is the best question you can put to a buyer, and it is a waste to answer it yourself by rebuilding first. Show it, watch what they do, and let that decide the next piece of work.

What showing tells you, person by person, on Pro:

  • Who opened it, and when, from a link made in their name.
  • Who came back, which is a strong sign.
  • Who brought in a colleague. A forwarded link asks the next person who they are, so you see the buying group.
  • What held them. Time on each screen and page, and how far through the tour they got.
  • What they said. Comments pinned to the screen, and their answer to what happens next. The answers are book a meeting, yes, get back to me, bring in a colleague, ask a question, or not for me.

The pipeline places each person from that evidence: sent, opened, engaged, said yes, later or not now. It counts what they did and never scores them.

How do you know it is worth making real?

Watch what people do, not what they say on a call. Someone who came back, brought in a colleague, asked a question or booked a meeting is telling you something a polite “looks great” never does. If nobody opens it, change the pitch before the product. If they open it once and go quiet, change the product.

The room ranks the people you sent it to in the order those signals matter. Who came most recently comes first. Among them, whoever came back most, then whoever brought in the most people, then whoever left the most comments and questions, then whoever spent longest inside. Who to call first, at the top of the app, names one person with the evidence in words, such as “seen today, back on Pricing, shared it with someone new”.

Then one of three things:

  1. Harden it — if several people came back and asked for more, and the prototype already does the job, make it safe for real data.
  2. Rebuild it — if they wanted it but it buckles under real use, take what they used to a developer as the brief.
  3. Drop it — if nobody came back after a second nudge, you have learned that for the cost of showing it.

What changes when real customers use it?

Real customers bring real data, and real data needs real security. The database needs rules on who can read each table. No key can sit in the code a browser downloads. Backups need to exist. And the free plan you prototyped on may not allow a business to run on it. This is where a developer usually comes in.

  • Database rules. Supabase says to turn on row-level security for every table its API exposes. Without it, a table can be read and changed by any role the database grants access to. Supabase says never to use a secret key in the browser, or let a customer see one.
  • Keys in the front end. Vite builds any setting whose name starts with VITE_ into the code it sends to the browser. It says those settings should never hold a secret, such as an API key.
  • The plan’s terms. Vercel’s Hobby plan is free, and Vercel says it is for personal, non-commercial use. GitHub says its free Pages hosting is not for running an online business, a shop, or software sold as a service.

Showing it needs none of this, as long as nothing real is in it. A demo on Roomi runs on mock data, every room tells its viewers so, and a container demo has no internet to reach a real system. The deploy scans for secrets and stops on one. Roomi is not where the real product lives, though: once people have said yes, it moves to a production host. Security explains how demos are kept apart. Swapping real data for mock data shows how to take the real records out, and the checklist before you send covers the rest.

What does it cost to find out?

You can start on Free, with a draft only your workspace opens or a public listing on the community. A private link for each person, and the record of what each one did, comes with Pro, at £4 a month or £40 a year, before VAT.

A public listing is public: anyone can open it. Keep a client’s name, logo and words out of one, and use them in a private room only with that client’s permission. Pricing has every plan, and the community shows what a listing looks like.

The four steps, in order

  1. Show it on mock data. Swap anything real for sample records shaped like the client’s world, and take out every key.
  2. Send one link a person. Make a link in each name, and send it yourself. Say who you are, how to reach you, and that the room records what they do there, as Roomi’s terms ask.
  3. Read what they did. Visits, returns, colleagues brought in, time on each screen, and their answers.
  4. Decide. Harden it, rebuild it or drop it, from what they did rather than what they said.

The Quickstart takes a demo from your folder to a live room. Founders shows the same loop used to test an idea before building it properly.

Questions people ask

Can I launch my Lovable or Bolt app as the real product?

Their own hosting will put it online. Before real customers use it, check three things. The database has rules on who can read each table. No key sits in the code the browser gets. And your plan allows commercial use.

Can Roomi host my real product?

No. Roomi hosts demos on mock data, for showing a product to the people you sell to. Every room tells its viewers that nothing they do reaches a real system. A product with real customers needs a production host.

Do I need a developer?

Not to show it. You can deploy a demo yourself, with Claude or a coding agent doing the technical part. To run it with real customers and their data, you usually do, or at least someone who has done it before.

Can I keep changing it after I send it?

Yes. Deploy again and every link opens the new build on its next load, so nobody’s link changes. A preview deploy lets you check a build in the room before your viewers see it.

My prototype uses real data. What now?

Swap it for mock data before anyone outside your team sees it. Ask your coding agent to read from sample files shaped like the real thing, with invented names and figures. The deploy also stops if it finds anything that looks like a live key.

Sources

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.

Find out who wants it before you build it properly.

Start free with a public listing, and move to Pro when you want a link for each person.

Get started freeSee pricing