- Limit the prototype to one person, one path and one result you can show.
- Iterate in small steps, and before sharing read the code for secrets, authorization and dependencies.
- At the end decide: throw it away, develop it or rewrite it properly.
A prototype in one evening is realistic if you understand what it is: a way to quickly test an idea, not the first version of a product. Builders and coding agents cut the building of screens from days to hours, but they do not cut the need for review or for a decision on what next. The plan below assumes work in a builder in the style of v0, which creates an app from a description and lets you deploy it or submit changes as a pull request, but the rules are the same in any tool. You will find a comparison of tools in the article App builders and code agents.
Hour one: scope and brief
Start with a narrow scope: one person, one path, one result that can be shown. For example “a person who has 10 minutes types in three data points and gets a ready weekly plan”. Write it in a few sentences, together with what the prototype must not do: logins, payments, real data. A narrow scope protects against the most common trap, a growing set of features of which none works properly. You describe the brief as in the first lesson of the plan, Describe your project in five sentences.
Hours two and three: iterations
Generate the layout, then one feature at a time. After each step check the result in the browser and fix it with a concrete command. Save versions so you can return to a working state: most tools keep a change history, and when the code is in a repository, a commit after each successful step is enough. Avoid commands such as “make it better”: describe what should change and how you will know it worked. If the tool starts breaking earlier elements, stop and undo the change instead of adding more fixes to a damaged state.
- 01ScopeOne person, one path, one result.
- 02SkeletonLayout and test data.
- 03FeaturesOne at a time, each with a commit.
- 04ReviewCode for secrets and permissions.
- 05DemoThree people, notes on reactions.
- 06DecisionThrow away, develop, rewrite.
Hour four: code review
Before you show the prototype to anyone but yourself, read the code as if reviewing somebody else’s pull request. Look for a few things. Keys and passwords in the code or in files that reach the browser. Places where user data enters a query without validation. A missing permission check on operations on data. Dependencies of unknown origin. In a GitHub repository you can enable code scanning, which automatically looks for vulnerabilities and errors. Among threats to LLM applications OWASP lists, among others, supply-chain vulnerabilities and improper output handling; if the prototype shows users what a model returns, treat it as untrusted data.
| What to look for | Why | |
|---|---|---|
| Secrets | API keys in client code | Any visitor can read them |
| Authorization | No check of who has access | One person's data visible to others |
| Input | User data without validation | Injection and bugs |
| Dependencies | Unknown or outdated packages | Supply chain |
| Data | Real personal data | Legal responsibility |
What to write down at the end of the evening
Before you close the laptop, write down five things: what the prototype can do, what it cannot, which design decisions were made, what risks the review found and what the conversation with users showed. This note is the most valuable result of the evening, because in a possible rewrite it replaces half a day of reconstructing knowledge. Also keep a link to the version you showed and the list of commands that gave the best result, because that is the seed of a future brief for the agent.
The demo and the decision
Show the prototype to three people from the target group and watch how they use it instead of talking. Note where they get stuck and what they ask. After the demo make one of three decisions. Throw it away: the idea did not work out, and the cost of learning was low. Develop it: the direction is good, the code is readable and the review showed no serious problems. Rewrite: the idea works but the prototype is unfit for maintenance. The last decision is fine too, because the prototype did its job. It is then worth taking the findings and test cases into the target version and writing the code with an agent working on the repository, which I describe in the article on the first session with Claude Code.
Last checked: 20 October 2026. Tools change; this plan does not depend on a particular product.