App and interface prototyping
App and interface prototyping before a single line of code is written. A clickable prototype shows what a person will do in the product and where they will stop, and it costs several times less than reworking things later.
Let us first separate three things that often get confused. A mockup shows how the product looks. A prototype shows what a person does in it and in what order: the screens are linked, the buttons respond, the transitions work, but there is no code behind any of it. An MVP is already a working product built small, used to test demand and money. A prototype sits between design and development and costs less than either.
The point of a prototype is that being wrong on it costs nothing. Moving a step, dropping an extra screen, realising that a five-field registration form is not wanted by anyone takes half a day here. The same thing after development takes weeks and negotiations about whose fault it was. That is why we push for a prototype even on small projects: it pays for itself on the first serious change.
A prototype is useful even before there is money for development. You can take it to an investor, to partners or to your own board and show them not a deck full of promises but a product they can touch with a finger on a phone. People react to that differently than to slides.
And third: a prototype is a shared language with the development team. From a finished prototype it is clear how many screens there are, which states are needed and what has to happen on the server side. An estimate after a prototype stops being guesswork.
From there the prototype turns into design and development: a mobile app, a website or web application, an online service. If the product has to be tested on real people and real money, the next step is an MVP, and if the question is broader still and sounds like whether to do it at all, start with business consulting. How this looks on a live project can be seen in the Battle of the Bees case: prototyping a mobile game and a Telegram Mini App is exactly this kind of work.
What the service covers
Any combination of the items below can be taken on its own.
Who the user is, why they come, what they have to do and what gets in their way. The list of screens comes from that rather than the other way round.
How the sections connect, what lives where, where a person lands after each action. Schematic, without styling, so the discussion is about substance rather than colours.
Screens linked by transitions, with the main states. It opens from a link on a phone and on a computer and can be shown to anyone.
Following the rules of the platforms: gestures, sizes, behaviour inside the messenger.
We give the prototype to the people the product is for and watch where they stop. This is the most useful part and the most underrated.
A description of the screen logic and states plus a development estimate by stage. You can take that either to us or to any other team.
How we work
We talk it through, go over the audience and the scenarios and record the constraints.
The map of sections and the path a person takes step by step. This is usually where it turns out that half of what was planned is unnecessary.
We build the screens and the transitions and show them in iterations.
A small group, observation, changes based on what we see.
The prototype, a description of the logic, a development estimate and a plan for the first weeks.
Stack and tools
Cases for this service
Frequently asked questions
A mockup shows how the product looks: styling, typography, colours. A prototype shows what a person does in the product and in what order: the screens are linked, the buttons respond, the transitions work. A prototype may carry no styling at all, and that is fine.
There is no code behind a prototype: it is a set of linked screens that show how the product behaves. An MVP is already a working product built small, with a server side and real data, used to test demand and money. A prototype is cheaper and faster, an MVP answers different questions.
It depends on the number of screens and the complexity of the scenarios. A small product fits into two or three weeks, a complex service with roles takes longer. We give an estimate after the analysis.
A clickable prototype available from a link, a description of the screen logic and states, and a development estimate by stage.
Yes, that is one of the reasons it is made. An estimate after a prototype is far closer to reality than an estimate from a written description.
No, but it is almost always worth it. The exceptions are very simple tasks and cases where the product already runs and one screen is changing.
Everything is set by the contract, and we put it in writing at the specification stage, before the work starts. The prototype source files and the documentation are handed over to you together with the rights to them.
Related services
Shall we discuss your task?
Tell us what needs to be done and we will come back with an estimate, the team composition and a plan for the first two weeks.