Is this a working application?

No, and the distinction matters. There is no database behind it, nothing is saved, and any number or name you see is one we placed there. What it does is respond to taps in the right order with the right transitions, which is enough for somebody to form an accurate impression of how the product works. Everything you would need a back end for — real accounts, real payments, real data — is a build, not a prototype.

Do we need the designs first?

You need screens, from somewhere. If you have a Figma file already, this is wiring and testing and sits at the bottom of the range. If the screens do not exist yet, creating them is product design work rather than prototyping, and it is quoted as such — that is the single biggest factor in what this costs and the one most often glossed over in a cheap quote.

Can it be used for real user testing?

Yes, and that is usually the highest-value reason to build one. Changing a prototype takes a day or two; changing built software takes weeks. Where testing is in scope we also write the test plan — the tasks, worded so they do not contain their own answer, what to watch for at each one, the questions to ask afterwards, and the questions that feel natural to ask and should not be asked.

Will investors realise it is not the real product?

They will if you tell them, and telling them is the right call. The point of showing a prototype is not to imply the software exists — it is to demonstrate that you have made specific decisions about how it works, which is what separates a founder with a plan from a founder with slides. Presented honestly, a prototype is a strength. Presented as shipped software, it becomes a problem the first time someone asks to try it.

Figma for the large majority of cases — it is faster to build, easier to change, and enough for both a demo and a test. Framer is the better answer when the thing being judged is the feel itself, real scrolling and real animation, or when the prototype needs to behave with real content. It takes longer and costs more, so it is a decision we make with you rather than a default.

Can this become the real product?

Not directly, and anyone who says otherwise is describing a different tool. What it becomes is the specification the build is quoted and written against, which saves more than it sounds like — a developer estimating from a prototype they can click through gives a far more accurate number than one estimating from a description.

UI/UX & Design

Interactive prototype

A link that opens on a phone and behaves like the real thing — every path wired, every dead end handled, and a way back from every screen.

From: $500–$4,000
Typical time: 1–3 weeks
Usually bought by: Founders

What this actually solves

Three quite different problems arrive here, and money is attached to each one.

The first is a meeting. A founder is showing an idea to an investor or a large customer, and a founder showing static pictures is not taken as seriously as a founder handing over a phone. The gap is not fairness, it is evidence — pictures show that you can describe a product, a prototype shows that you have decided how it behaves.

The second is the expensive one. A team is about to commit weeks of engineering to a flow that nobody outside the building has tried. Changing a prototype after somebody gets stuck in it is a day or two of work. Changing the same thing once it is built, tested and deployed is weeks, and by then there is a sunk cost arguing on its behalf.

The third is internal. Two people disagree about how a feature should work, the argument has now happened repeatedly, and neither description is convincing anyone. A prototype ends it, because both versions become clickable and one of them is obviously worse the moment a person tries to use it.

What we do, and in what order

Map the paths. Which journeys have to be clickable, in what order, and for what audience — a demo narrative and a test script want different things wired. Confirm the screens that exist and identify the ones that are missing. Half a day to a day.
Wire it. Connections from every interactive element, transitions chosen per screen rather than left at default, overlays for modals and dropdowns, scrollable regions defined, and Smart Animate where something genuinely needs to move between two states rather than cut. Two to five days.
Sweep for dead ends. Every element that looks tappable gets a destination. Where a part of the product is genuinely out of scope for this demo, it goes to a small screen saying so rather than doing nothing. A way back is added from every screen, which is the most frequently omitted connection in prototyping and the one that ends demos early. Half a day to a day.
Walk every path on a real phone. Not the desktop preview. Tap targets that are comfortable with a cursor are a different proposition under a thumb, and the transitions read differently at actual size. Half a day.
Hand it over. The link, plus a short screen recording walking through what is clickable and what is not, so that whoever presents it is not discovering the prototype live in front of an investor. Half a day.
Where testing is included, write the test plan. Three tasks phrased as goals rather than instructions — somebody is asked to change their phone number, not to open the settings menu. For each task, what behaviour indicates a person is stuck. Three follow-up questions per task that ask for reasons rather than opinions. A short list of the questions that will be tempting to ask and should not be. And a one-page form for recording each session. One to two days.

Built in Figma's prototyping mode for most work, Framer where the feel itself is what is being judged, and shared as a link that opens on any phone without an account.

What moves the price

The range is $500–$4,000 and it is set almost entirely by three things.

Whether the screens already exist. A complete Figma file that only needs connecting is a short piece of work at the bottom of the range. Designing the screens first is product design, priced as product design, and we will say which of the two you are buying before quoting.

How real it has to feel. Cut transitions and simple overlays are quick. A prototype where elements move convincingly between states, with staged animation and considered timing, takes roughly three times as long for the same number of screens.

Whether user testing is part of it. Wiring a prototype and running a test programme on it are separate jobs. The test plan, the recruitment, the sessions and the write-up all sit outside the wiring, and are quoted as their own scope.

What usually goes wrong

Only the happy path is wired. Everything works if the person clicks exactly where the demo expects. In an actual meeting somebody clicks the profile icon out of curiosity, nothing happens, and their conclusion is not that the prototype is limited — it is that the product is broken. Anything that looks like a button gets a destination, even if that destination is a screen explaining it is outside this demo.

No route back. It is the single most forgotten connection. A viewer opens a detail screen, wants to return to the list, and there is nothing. On a phone there is not even a browser back button to rescue them, so the demo simply stops. Every screen gets its return path before the prototype is considered finished.

Test tasks that contain their own answer. Telling a participant to open the settings menu and change their number tests whether they can read. Telling them they want to change the phone number on their account tests whether the product makes that findable, which is the only thing worth learning. Prototypes tested with instruction-shaped tasks reliably produce the conclusion that everything works, right up until launch.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Is this a working application?: No, and the distinction matters. There is no database behind it, nothing is saved, and any number or name you see is one we placed there. What it does is respond to taps in the right order with the right transitions, which is enough for somebody to form an accurate impression of how the product works. Everything you would need a back end for — real accounts, real payments, real data — is a build, not a prototype.
Do we need the designs first?: You need screens, from somewhere. If you have a Figma file already, this is wiring and testing and sits at the bottom of the range. If the screens do not exist yet, creating them is product design work rather than prototyping, and it is quoted as such — that is the single biggest factor in what this costs and the one most often glossed over in a cheap quote.
Can it be used for real user testing?: Yes, and that is usually the highest-value reason to build one. Changing a prototype takes a day or two; changing built software takes weeks. Where testing is in scope we also write the test plan — the tasks, worded so they do not contain their own answer, what to watch for at each one, the questions to ask afterwards, and the questions that feel natural to ask and should not be asked.
Will investors realise it is not the real product?: They will if you tell them, and telling them is the right call. The point of showing a prototype is not to imply the software exists — it is to demonstrate that you have made specific decisions about how it works, which is what separates a founder with a plan from a founder with slides. Presented honestly, a prototype is a strength. Presented as shipped software, it becomes a problem the first time someone asks to try it.
Figma or Framer?: Figma for the large majority of cases — it is faster to build, easier to change, and enough for both a demo and a test. Framer is the better answer when the thing being judged is the feel itself, real scrolling and real animation, or when the prototype needs to behave with real content. It takes longer and costs more, so it is a decision we make with you rather than a default.
Can this become the real product?: Not directly, and anyone who says otherwise is describing a different tool. What it becomes is the specification the build is quoted and written against, which saves more than it sounds like — a developer estimating from a prototype they can click through gives a far more accurate number than one estimating from a description.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Interactive prototype All UI/UX & Design services