Build a working app prototype with AI and put it in front of people

Why a working prototype tells you more than a mockup

Static screens test whether people like how something looks. They rarely test whether people can use it, because the tester has to imagine what happens after each tap, and the person running the session ends up narrating the product. A clickable app prototype that really responds removes that narration. The tester types into a real field, sees a real total change, gets a real empty state when they delete the last item. Their confusion is about your design, not about the prototype's gaps.

It also changes the questions you can ask. With a mockup you ask "would you use this?", which people answer politely. With something that works you can set a task ("add next Tuesday's shift and see what that does to your weekly hours") and watch where they hesitate.

Decide what the prototype has to prove

Before describing anything, write down the one or two questions the test should answer. That keeps the build small and the sessions focused. Typical ones:

• Comprehension: do people know what the main screen is for within a few seconds?
• The core task: can they complete the one job the product exists for, unaided?
• The awkward moment: what happens at the edge you're unsure about: an empty list, a mistake to undo, a long name that wraps?
• Willingness: after using it, would they swap their current spreadsheet, notebook or app for it?

Anything that doesn't serve those questions can be left out or faked. A settings page nobody will open in a twenty-minute session is wasted effort, however easy it is to generate.

How to describe it to Anticode

Describe the person, the task and the screens in a few sentences, and say what the sample data should look like. For example: "A prototype of a shift-swap app for a café team. Screens: this week's rota, a request to swap a shift, and a list of open swap requests. Use eight sample staff and a realistic week. Mark everything as demo data." The Architect replies with a short plan (name, screens, look, features) and may ask up to three questions where the answer changes the build, each with suggested answers you can tap.

When you choose Build it, the model writes the whole app as one HTML document, and you can watch the code stream in. New app builds can also be opened in a headless browser at phone and laptop widths, screenshotted and clicked through, with errors fed back for fixing, when that review service is available.

Make the fake parts honest

Anticode apps run in a sandbox with no network, so anything that would normally need a server is simulated inside the page: other users are sample people, "sent" messages land in a local list, and a sign-in screen accepts anything. The app labels these as demo data where it matters. Keep that labelling visible during testing. Testers who think they're using a live system make different, riskier choices than testers who know it's a model, and you want the second kind of feedback at this stage.

What does persist is anything the app saves to the tester's own browser. If someone adds three items, closes the tab and comes back tomorrow, the items are still there on that device. That's enough for a diary study over a week, as long as each tester sticks to one phone or laptop.

Running the sessions and changing the build

1. Publish the prototype to its anticode.dev address and send testers the link. Nothing to install.
2. For stakeholders, send a client review link instead: they can open the current preview without an account and leave comments tied to a section. Links expire after 14 days by default and you can revoke them.
3. After each round, ask for changes in plain words ("move the swap button onto each shift card"). Recent saves are kept in version history (up to a number set by your plan), so you can show round one and round three side by side or go back.

What a single-browser prototype can't test

Be clear with yourself about the boundary. A sandboxed prototype runs on one device at a time, so it can't test:

• Anything between people: real notifications, shared lists, two testers seeing each other's changes.
• Real sign-in, permissions or account recovery.
• Live outside data, payments, or AI features inside the app (they can only be imitated with fixed sample responses).
• Performance with real data volumes or slow networks.

When the idea survives testing, the Next.js export is the step towards a real product. It covers app builds and gives you a standard App Router project in TypeScript with Postgres through Prisma, email sign-in, customer and staff roles and an admin area. It's a starting point a developer will extend, not a finished multi-user app, and you can push it to a GitHub repository you pick. The guide to exporting to Next.js covers what's in it. If you need production multi-user features without writing code, a backend-backed no-code tool may suit you better than either.

Questions people ask

Is this an AI app prototype generator or a design tool?

It builds working code, not frames on a canvas. You get a real app in the browser, which suits usability testing; if you need pixel-level design files for a design team, use a design tool alongside it.

Can testers use it on their phones?

Yes. The published app is a web page that works in a phone browser, and anything it saves stays on that phone.

Can I see what testers entered?

Not what they saved inside the app, which stays on their device. If you add a feedback or contact form, those submissions reach you by email and in the dashboard.

Does the prototype become the real app?

It can become the starting point. The Next.js export turns it into a project with a database and sign-in that a developer can build on.