How to Create a Software Prototype: Types, Steps, Testing and Tools
For a founder, product owner or designer with an idea and no budget to build it twice: what a software prototype is, the types, and the seven steps from a question to a tested, clickable version.
A software prototype is a model of a product that looks and behaves enough like the real thing for someone to try it, so you can learn before anything is built. You create one by writing the one question it must answer, choosing how detailed it needs to be, mapping and building the screens for one task, linking them so they click, and watching five people use it. A first prototype takes about a day.
What This Guide Covers
- Wireframe, mockup, prototype and MVP in one paragraph
- The four types of prototyping, and the fidelity levels
- Seven steps from a question to a decision
- A worked flow for one task: booking a first appointment
- A five-person test script you can read out
- What the AI prototype builder route gives you, and what it does not
Wireframes have their own guide: the app wireframing guide.
TL;DR Quick Summary
Create a software prototype in seven steps. 1. Write the one question it must answer. 2. Pick the fidelity that answers it: paper, clickable or coded. 3. Map the screens for one task, in order. 4. Build those screens with real copy and realistic data. 5. Link them so the task can be clicked through. 6. Watch five people try the task while thinking aloud. 7. Fix and test again, change direction, or start building. Five users find about 85% of usability problems (Nielsen, NN/g).
Try the AI prototype builder →Table of Contents
The ladder and the types first, then the seven steps, then tools and mistakes.
- Wireframe, mockup, prototype
- What software prototyping is, and the four types
- Step 1: Write the Question the Prototype Must Answer
- Step 2: Choose the Fidelity for That Question
- Step 3: Map the Flow for One Task
- Step 4: Build the Screens
- Step 5: Wire the Interactions
- Step 6: Test It With Five People
- Step 7: Decide: Iterate, Pivot or Build
- Prototyping tools
- Mistakes that waste a prototype
- Frequently asked questions
Wireframe vs Mockup vs Prototype, in One Paragraph
The three words describe three levels of detail. In the definitions our AI mockup generator page uses: wireframes show basic structure and layout with no visual design (boxes and lines); mockups add visual detail, real colours, fonts, images and branding; and prototypes add interactivity, clickable buttons, page transitions and user flows. That is the whole difference this guide needs. If you are still deciding what goes on each screen, start with the app wireframing guide and come back with your wireframes. This guide starts where people need to click something.
What Is Software Prototyping, and What Are the Four Types?
Software prototyping is building an early, incomplete version of a program so that people can try it and you can find out what the finished product should be. "Type" gets used in two ways, so here are both. The first is the software-engineering view, which is about what happens to the prototype afterwards:
| Type | What happens to it | Use it when |
|---|---|---|
| Throwaway (also called rapid) | Built quickly to learn something, then discarded. Nothing from it ships. | The requirements are unclear and you need to test ideas cheaply. |
| Evolutionary | Refined again and again until it becomes the product. | You understand part of what is needed and are ready to keep and extend the first build. |
| Incremental | The final product is built as separate prototypes that are merged at the end. | A large system can be split into parts that are designed one at a time. |
| Extreme | Used for web apps: static pages first, then a simulated services layer, then the real services. | You are building a web app and want working screens before the back end exists. |
The four types follow the standard taxonomy summarised in Wikipedia's software prototyping entry, read 1 October 2026.
The second view, the one most designers mean, is about how real the prototype looks and feels:
Paper (low fidelity)
Sketches on paper or a whiteboard, moved by hand as the person "taps". Minutes to make, and good for testing the order of screens.
Clickable (medium to high fidelity)
Designed screens linked so a person can tap through a task on a phone or laptop. The usual meaning of "prototype".
Coded (high fidelity)
A working build with real behaviour, such as a generated website or a small coded app. Slower, and right when speed or real data is the question.
Prototype or MVP? A prototype tests whether people can use the idea. A minimum viable product tests whether they will, with real code, real users and usually real money. Our guide to what an MVP is covers the second step; most teams should prototype first.
Step 1: Write the Question the Prototype Must Answer
A prototype that tries to answer everything answers nothing. Write one question it must answer, phrased as something you can watch happen, before you draw a screen.
The question: can a new patient book a first appointment in under a minute, without help?
Questions a prototype can answer
- Can people find the booking button?
- Do they understand the difference between the two appointment types?
- Do they trust the confirmation enough to stop calling the clinic?
Questions it cannot answer
- Do people like it? (They will say yes to be polite.)
- Will they pay for it? (That is what an MVP is for.)
- Will the app make money?
If you are not yet sure the idea is worth a prototype at all, how to validate an app idea covers the cheaper checks to run first: talking to customers, a landing page, and pre-orders.
Step 2: Choose the Fidelity for That Question
Fidelity is how close to the real product the prototype looks and behaves. Pick the lowest fidelity that can answer your question, because every extra level costs time you will spend again after the first round of changes.
| If your question is about | Build | Typical time |
|---|---|---|
| The order of screens, and what goes on each | Paper or whiteboard sketches | An hour |
| Whether people can complete a task | A clickable prototype | A day |
| Speed, real data, or how it behaves on a real device | A coded prototype | Days |
| Whether people will use it every week, or pay | An MVP, not a prototype | Weeks |
The clinic question is "can a new patient complete the booking", so the example uses a clickable prototype: real-looking screens, linked, on a phone.
Step 3: Map the Flow for One Task
List the screens a person sees to complete the one task, in order, and nothing else. A prototype of the whole app takes weeks and tests none of it well; a prototype of one task takes a day and tests it properly.
Screen 1
Home
Clinic name and opening hours
Location
Book a first visit
Screen 2
Choose a service
Initial assessment, 45 minutes
Follow-up, 30 minutes
Initial assessment
Screen 3
Pick a time
A week of dates
Four open slots for the day
Tuesday 10:30
Screen 4
Your details
Name, phone, email
Reason for the visit (optional)
Confirm booking
Screen 5
Confirmed
Date, time and address
Add to calendar, cancel link
Done
The flow for the clinic task, drawn for this guide: five screens, one action each. Anything not on this path, such as the team page or the blog, stays out of the prototype.
Write each screen's single job under its name. If a screen has two jobs, it is usually two screens, or one job too many.
Step 4: Build the Screens
Now design the screens on your map. At prototype stage only a few design choices matter, and they are the ones that change what people do. Our guide to how to design a mobile app covers the full design process; these are the rules for a prototype.
- Real copy, not lorem ipsum. People read the words to decide what to tap. "Book a first visit" and "Book now" test differently.
- Realistic data. Real-looking dates, times, names and lengths of text. A layout that works with "Jo" can break with "Alexandra Fitzgerald-Smith".
- One obvious main action per screen. The button for the next step is the most visible thing on the screen.
- The awkward states. A day with no free slots, and a form with an error, so you can see what people do when it goes wrong.
Worth doing now
- Real copy and realistic data
- Clear main buttons
- Empty and error states for the one task
Skip until later
- Final branding and colours
- Animations and transitions beyond what the flow needs
- Screens that are not on the map
If you would rather start from generated screens than a blank canvas, an AI tool such as our UI design generator can draft a first set from a description, which you then edit to match the map.
Step 5: Wire the Interactions
Linking the screens is what turns a set of designs into a prototype. In a design tool with a prototype mode, you draw a link (often called a hotspot) from each button to the screen it should open, choose a simple transition, and set the screen the prototype starts on.
- Link the main path first. Every main action on the map opens the next screen.
- Add a way back. A back arrow or cancel on each screen, or people get stuck and the test ends early.
- Link the awkward states. One tap that shows the no-slots day, and one that shows the form error.
- Avoid the dead end. A tappable-looking element that does nothing. People will tap it, and you will spend the test explaining it.
The AI route. Appy Pie AI's AI prototype builder starts from a description instead of linked frames. When we checked the page on 1 October 2026, its prompt box handed the description to the same AI generator Appy Pie AI uses for websites, so what comes back is a working website rather than design screens with hotspots: a coded prototype, in the terms of step 2.
What the generator does next, from our own run. We ran the same generator with a different brief on 29 September 2026, for our sales funnel guide, on a free account. A one-page draft website came back in under a minute: the copy followed the brief, while the hero image, photos and testimonials were template placeholders to replace. The next screen asked for an upgrade before the editor opened. We did not run the clinic brief through to a result, so this guide does not show one for it.
Step 6: Test It With Five People
Watch five people try the task. Not teammates, not friends who know the idea: five people like the customer. In Nielsen's 2000 article on usability testing, he found that the first five participants revealed about 85% of the usability problems, and that the best results come from testing no more than five users and running as many small tests as you can afford. Test five, fix, and test five more.
The five-person test script
About 15 minutes each. Read it the same way every time, and record the screen and the voice if they agree.
0:00
Welcome
Thanks for helping. We are testing this design, not you, so nothing you do is wrong. Please think out loud: say what you are looking at and what you expect to happen.
0:01
Set the scene
Imagine you have hurt your back and a friend recommended this clinic. You have just opened its app.
0:02
The task
Book a first appointment for next Tuesday morning.
Then stop talking. Do not point, explain or help.
During
Watch and note
Write down every hesitation, wrong tap and question, and the screen it happened on. If someone is stuck for a minute, note it and move them on.
After
Three questions
What was the hardest part?
What did you expect to see that was not there?
How sure are you, from 1 to 5, that the booking went through?
End
Thank them
Thank them and stop the recording. Write up the notes the same day, while you still remember what each one meant.
Then put everything in one table. The problems that more than one person hit go to the top.
| Problem | People who hit it (of 5) | How bad | Fix to try |
|---|---|---|---|
| Did not see the Book button below the opening hours | 3 | Blocks the task | Move the button above the hours |
| Expected prices on the services screen | 2 | Slows them down | Show the price next to each service |
| Unsure the booking was saved | 2 | Causes a phone call | Add "We have emailed your confirmation" |
The table above shows the format with example entries, not results from a real test. A prototype test is about whether the design works; testing whether the finished app works on many devices is a later, separate job, covered in our guide to mobile app testing.
Step 7: Decide: Iterate, Pivot or Build
The test answers your question from step 1, so make the decision it points to and write it down.
Iterate
People could mostly do the task, but hit the same few problems. Fix those, keep the question, and test five new people.
Pivot
People did not understand the idea or wanted something else. Change the approach, not the button colour, and go back to step 1.
Build
Most people completed the task without help. Move on to an MVP or the real product.
What "build" means depends on the route. A clickable prototype becomes the specification for an MVP: nothing in it ships, but every screen and decision carries over. On a no-code builder, the next step can be the app itself; how to create an app walks through it.
Prototyping Tools: What Each Is For
There is no single best tool; it depends on the fidelity you chose in step 2. Figma is a design tool with a prototype mode for linking frames and adding transitions, and it is where most clickable prototypes are made. Proto.io is built only for clickable app prototypes, with ready-made mobile components. Canva has templates for quick screen designs you can present as a simple prototype. Uizard generates editable screens from a text description or a photo of a sketch. Appy Pie AI's AI prototype builder generates a working website from a description, as shown in step 5. For an AI tool, look for three things: it turns a description into screens you can edit, it lets you link or click through them, and it shares the result as a link that opens on a phone.
Mistakes That Waste a Prototype
Prototyping the whole app
Thirty screens take weeks and test nothing well. One task, five screens, one day.
Testing with teammates
People who built it know where everything is. Test with people like the customer.
Polishing before testing
Colours, logos and animations come after the flow works. Polish makes people comment on looks, not on the task.
Treating the prototype as the spec
A prototype answers one question. Error handling, edge cases and the screens you left out still need deciding.
Frequently Asked Questions
How can I build my own prototype?
Write the one question it must answer, sketch the screens for one task on paper, then design those screens in a tool with a prototype mode and link each button to the next screen. Share the link to a phone, and watch five people try the task. A first prototype takes about a day, and no code is needed.
What are the four types of prototypes?
In software engineering the four types are throwaway (or rapid), which is built to learn and then discarded; evolutionary, which is refined until it becomes the product; incremental, where the product is built as separate prototypes that are merged; and extreme, used for web apps, which goes from static pages to simulated services to real ones. Designers also describe prototypes by fidelity: paper, clickable and coded.
What is software prototyping?
It is building an early, incomplete version of a program so that people can try it and you can learn what the finished product should be, before you spend money building it. The prototype can be paper sketches, linked design screens you can click through, or a small working build.
Which AI tool is best for making a prototype?
It depends on what you need to test. Look for a tool that turns a description into screens you can edit, lets you click through them, and shares the result as a link that opens on a phone. Uizard generates editable screens from text or a sketch, Figma is where most clickable prototypes are linked and shared, and Appy Pie AI's AI prototype builder generates a working website from a description.
How long does a prototype take to make?
About a day for one task at clickable fidelity: an hour to write the question and map the flow, a few hours to design the screens, an hour to link them, and half a day to test with five people. A paper prototype can take an hour; a coded one takes days.
What is the difference between a prototype and an MVP?
A prototype tests whether people can use the idea, with designs or a small build and no real users. A minimum viable product tests whether people will use it, with real code, real users and usually real money. Most teams prototype first, then build the MVP.
Can a prototype become the real app?
A clickable design prototype does not; it becomes the specification the real app is built from. An evolutionary prototype is built to grow into the product. A website generated by an AI builder is already a real site that can be published, on a paid plan, though it still needs editing and testing first.
How much does a software prototype cost?
A paper or clickable prototype mostly costs time: several design tools have free plans, so check what each includes when you start. On Appy Pie AI, generating a website prototype is free, and publishing it needs a website plan, from $36 a month on the US pricing page in October 2026. Agency and freelancer prices vary too widely for an honest average, so ask for a quote against your flow map.
Your Flow Is Mapped. Try It as a Prototype.
Describe the screens for your one task, and Appy Pie AI generates a working first version you can open on a phone.
Try the AI Prototype BuilderOne Question, One Task, Five People
Write the question, pick the lowest fidelity that answers it, map and build the screens for one task, link them, and watch five people try. Fix what three of them hit, test again, then decide. A day of prototyping is the cheapest way to find out what to build.
Try the AI prototype builder →
Aasif Khan
Head of SEO and Growth Marketing Lead at Appy Pie AI with 17+ years in digital marketing and scalable growth strategies.
Abhinav Girdhar
Founder and CEO of Appy Pie AI, one of the largest no-code and AI app platforms, with 10M+ apps and websites created.