How to Build an App Prototype You Can Tap (2026)

By Sigsten Gustavii· 27 October 2026· 8 min read

To build an app prototype, write down the question it must answer, build only the screens that answer it, put it in front of a handful of the people it is for, watch what they do, and change it until the answer is clear. With an AI builder like Borel, the prototype is a real native app from the start, so nothing is thrown away.

Prototypes used to be a trade-off: cheap and fake, or real and slow. AI builders changed that. A working prototype, one where people can type, save and come back to their data, now takes about as long to make as a polished mockup, and it tells you far more. People behave differently when the app actually works.

Start with the question

A prototype that tries to answer everything answers nothing. Pick one or two questions:

• Will people understand it? Can someone new add an item without help?
• Will they come back? After three days, do they still use it?
• Is this the right feature? Do they use the thing you think matters, or something else?
• Will they pay? Do they tap the Pro button, and what do they say when they see the price?

Write the question at the top of your notes. It decides which screens to build and which to leave out.

Build only what answers it

A prototype for "will people understand it?" needs the opening screen, the main action and the result. It doesn't need settings, accounts or a polished empty state for every list. Each extra screen is something to explain and something to break. With Borel, adding them later is a sentence, so leave them out now.

Make it real enough

The point of a working prototype is that it behaves like the app. Make sure these are real:

1. Data that saves, so people can come back tomorrow and find what they added.
2. Realistic content, not lorem ipsum: real recipe names, real prices, real dates.
3. The core interaction, whatever it is: the scan, the swipe, the timer, the chart.
4. Native feel: iOS navigation, Dynamic Type and dark mode, which SwiftUI gives you for free.

Leave out what isn't part of the question: payment, sharing, notifications to other people.

A note on data: a prototype that keeps everything on the phone needs no accounts and no cloud, so it costs nothing to run while people test it. Ask Borel to keep the data on the phone with SwiftData until the idea is proven; adding accounts and a cloud database later is a single message.

Test with about five people

Usability research has long found that a handful of testers reveal most of the problems a design has; Nielsen Norman Group's well-known guidance is to test with about five people and iterate. For an app prototype:

Where testers try it

The iOS Simulator in your browser runs up to two hours a day on the free plan and without a daily limit on Pro. Borel Companion, which comes with Pro, installs the app on your iPhone from a Windows PC or a Mac. TestFlight lets you invite up to 10,000 external testers once the build is uploaded.

What to measure

Small tests don't need analytics, but they do need notes. For each tester, write down:

• Time to the main action: how long until they added a meal, logged a set or saved a place.
• Wrong turns: every tap that went somewhere they didn't expect.
• Their words: what they called things, which often makes better labels than yours.
• What they tried that wasn't there: the feature requests that come from behaviour, not opinion.
• Whether they came back, if they had it for a few days.

After five people, the pattern is usually obvious. Change the biggest problem, then run another small round.

From prototype to product

With a mockup, the next step is rebuilding everything as code. With a working prototype built in Borel, the next step is the same app with more in it. Every change is a new version you can roll back, the code is real SwiftUI you can download, and when the answers are in, you add accounts, payments and polish, then publish from the same project. Nothing is thrown away except the screens you learned you didn't need.

Common prototype mistakes

• Building the whole app. If it takes more than a few days, it isn't a prototype.
• Testing with friends who are being kind. Find people who match the audience and have no reason to flatter.
• Explaining while they test. If you have to explain it, the app has to explain it later.
• Asking "would you use this?" People are polite. Watch what they do instead.
• Changing ten things at once. Then you don't know which change worked.

How to choose the right way to prototype

• Borel, for a working native iPhone prototype from a description that becomes the real app.
• A design tool, for testing the look of screens before anything works, or when a designer leads.
• Paper, for the opening hour of an idea.
• [Lovable](/compare/lovable), if the product is a web app rather than an iPhone app.

How to do it with Borel, step by step

Step 1: Describe only what the question needs

Make a prototype of a meal planner to test whether people understand it. One screen shows this week, Monday to Sunday, with a dinner slot per day. Tapping a slot lets me type a meal or pick from 20 example meals with real names. A second screen builds a shopping list from the week's meals, grouped by aisle, with tick boxes. Save everything on the phone. No accounts, no settings.

Borel's planner, Penny, asks about anything unclear, then Rivet writes it in Swift with SwiftUI. It opens in the simulator in your browser in a few minutes.

Step 2: Try it yourself

Use it for ten minutes as if you were a stranger. Fix anything obviously broken with a short message.

Step 3: Test with five people

Share your screen or hand over your phone. Note where people stumble, change one thing, and test again.

Step 4: Grow it or drop it

If the answer is yes, keep building in the same app. If it's no, you spent an afternoon instead of a season. See pricing for plans, and read how to make an iPhone app with AI for the full route to the App Store.

The Bottom Line

A prototype exists to answer a question cheaply. With an AI builder, the cheapest answer is now a working app: real typing, real saving, real native screens, running in your browser the same afternoon. Ask one question, build only what answers it, watch five people use it, and keep the app if the answer is yes. Describe your idea on Borel and tap through it today.

I believe the cheapest answer to an app idea is now a working app. Describe yours and watch five people use it.

– Sigsten

Make your iPhone app in Borel

Describe the app you want and see its first screens before you pay anything.