How to make an app prototype: five kinds, and which one answers your question

What is an app prototype, and what is it for?

A prototype is a model of an app that is built to answer a question, not to be released. It can be a drawing, a set of linked screens or a rough working version. It is not a first release. A first release (an MVP) is something real people use over time. A prototype is something real people react to once or twice so that you can learn before you build properly.

That difference changes how you build it. Nobody will ask whether a prototype scales, whether it is secure or whether the code is tidy. It only needs to be good enough for a person to understand what is being shown, and honest enough that their reaction tells you something true. The guide to scoping an MVP and what an MVP is cover the next stage.

Ask first what you want to find out. Different questions need different prototypes.

• Do people understand what it does? Show a sketch or a landing page.
• Is the flow easy to follow? Use clickable screens.
• Will the answer be good enough to use? Use a coded prototype or a manual version, so that real output is produced.
• Will anyone come back or pay? Use a rough working version in someone’s hands for a week, or a payment link on a simple page.

Which type of prototype should you make?

You can combine them. A common sequence: sketch the main screen, test a clickable mockup with five people, then build a coded prototype only for the flow that confused no one. Skipping the mockup is fine if the real risk is whether the output is useful. For an app that classifies, summarizes or recommends, the output matters more than the screens, so build the coded prototype early.

How do you build a prototype in one day?

This plan assumes a clickable mockup followed by a coded prototype. Adjust to the type you chose.

1. Hour 1: write the question. One sentence: “I want to learn whether [person] can [do the main job] without help.”
2. Hour 1: pick the main flow. List the steps a user takes from opening the app to getting the result. For most apps it is three to six screens. Everything else is out of scope.
3. Hours 2 to 3: sketch it on paper. One rectangle per screen. Show it to one person and ask what they think each screen does.
4. Hours 3 to 5: make it clickable. In Figma, frames are the screens and connections link them. Figma’s prototyping guide says prototyping is available on all plans and that you can share the whole prototype or a link to a flow starting point. Use real words and real sample data, not placeholder text.
5. Hours 5 to 7: build the real part, if the question needs it. Use an AI coding agent for one screen and one real function. The prompt below is a start.
6. Hour 8: write the test script, the tasks you will give testers, and decide how you will record what happens.

Build a throwaway prototype of [app name]. Its only purpose is to find out whether [person] can [main job] on their own.

Build exactly this flow:
1. [Screen 1: what the user sees and does]
2. [Screen 2: what the user sees and does]
3. [Result screen: what the user gets]

Rules:
- Web page, mobile first. No accounts, no database, no payments.
- The one real function is [what must actually work, e.g. turn a pasted receipt into a total]. Everything else may be fake and hard-coded; mark every fake with a visible comment in the code.
- Use real sample data from this list: [paste 3 real examples].
- Keep it under [300] lines in [3] files.
- Show clear errors if the input is empty or too long.

When finished, tell me how to run it and list every shortcut you took. Do not add features I did not ask for.

The point of marking the fakes is honesty. Testers will think a hard-coded answer is a real one, and you will too, a week later. The guide to building an app with Claude Code and how to vibe code explain how to run this loop. An idea on the board that is prototype-sized is Meeting cost ticker, a single screen with one number that changes.

How do you test a prototype?

Watch five people from your target group use it. Five is a practical start: patterns show up quickly, and you can run more rounds after you fix what you found. If the five are friends who want to be nice, you learn nothing, so find people who have the problem.

1. Explain very little. Say what the prototype is and that you are testing the design, not them.
2. Give a task, not instructions. “Find out whether you can afford this” works. “Tap the green button” does not.
3. Stay quiet. Ask them to think aloud. When they get stuck, wait and note where.
4. Record what they do, not what they say they would do. Note hesitations, wrong taps and questions.
5. Finish with three questions. What did you expect to happen? What was confusing? Would you use this next week, and for what?

Tester: [first name, role]   Date: [ ]   Prototype version: [ ]

Task 1: [e.g. add your first item]   Done without help? [yes / with a hint / no]   Time: [ ]
Where they hesitated: [ ]
What they said, word for word: [ ]

Task 2: [ ]   Done without help? [ ]   Time: [ ]
Where they hesitated: [ ]

What they expected the app to do: [ ]
What confused them: [ ]
Would they use it next week? Why or why not: [ ]
One thing to change before the next tester: [ ]

After five sessions, tally the problems. Fix those that two or more people hit, run three more sessions, and compare. The free App Idea Validation Planner can draft the questions to ask before a session.

How do you get a prototype onto people’s phones?

• Share a web link. A mobile-first web page opens on any phone with no install. It is the easiest route for a coded prototype.
• Share the design-tool link. A clickable mockup can be opened in a browser by anyone you share it with.
• Use TestFlight for a native iPhone prototype. Apple’s TestFlight page says you can invite up to 100 internal testers from your team and up to 10,000 external testers, and that external testing needs your first build approved by App Review. That is more setup than a prototype usually deserves. Test the idea on the web first.

The guide to building an iPhone app covers the native route when you reach it.

What do you do with the prototype afterwards?

Decide, then act. There are four outcomes.

Keep the prototype for reference, but do not turn it into the product by default. Code made to be thrown away often lacks error handling, tests and security. If you build the real app, start a fresh project and reuse what you learned. If you will not build it, you can post the idea on the board with your test notes as evidence, and browse what others have posted for prototypes worth a weekend.