Prototyping with AI.

What exists is a usable piece of software in which two or three flows work from beginning to end — not a picture, not a slide deck, but something you can hand to a stranger. That is what separates an AI-assisted prototype from a clickable mock-up: there are real inputs, real reactions and real error messages when you do something unexpected.

Concretely that might be: a booking flow where you genuinely enter a date, a service and contact details and see a confirmation. A configurator that calculates an indicative price from your inputs. An internal tool that filters, sorts and exports a list. A portal in which two different roles see different things. In every case with test data, never with real personal data.

What does not exist is completeness. The prototype can do exactly the paths it was built for. Leave them and it gets ugly — deliberately so. Every additional side path costs time that contributes nothing to the actual question. The visual result follows the same principle: recognisable enough to be judged, not polished enough to be defended. Full design work belongs in UI/UX design, not in the prototype.

The sequence is always the same: sharpen the assumption, then build, then test with real people, then decide. The order matters more than the tools — reverse it and start by building, and all you test at the end is whether people like what you built.

• Day 1 — assumption and stop criterion. We write one sentence stating what is to be tested and a second describing how we would recognise failure. Plus the task the test participants will later attempt. Without those two sentences we do not start.
• Day 1–2 — scope. Which two or three flows carry the assumption? Everything else is marked "not included" in writing. A rough wireframe is enough as a template; polish here would be wasted time.
• Day 2–5 — build. This is where the AI tools have the greatest effect, because something new is being built with no legacy in the way. We work in short rounds: build, try, refine. You usually see the first usable version by day two or three.
• Day 5–7 — test. Five to eight people from the target group, 30 to 45 minutes each, a task rather than an opinion. We watch and do not help, even when it hurts.
• Day 7–10 — evaluate and decide. Observations, figures and a written recommendation: continue, change the scope, or stop. Including the question of what a production system would additionally need.

The rhythm also works remotely. In the Zurich, Zollikon and Küsnacht area we are happy to attend the test sessions on site, because watching in the room shows more than a screen share does. Across the rest of Switzerland we run the same sessions by video; the loss in insight is slight, the saving in effort considerable.

What gets left out is everything that concerns operations and contributes nothing to the learning. That is fine, because a prototype is not software meant to run — it is an experiment meant to answer a question. We write the omissions down before we start, so the boundary does not become a matter of negotiation later.

• No robust access control. Roles are indicated, not secured. The prototype runs in a closed environment.
• No real personal data. Test data looks real but is invented. That removes the entire data protection discussion from the learning phase.
• No scaling, no operational monitoring. Eight test participants are not eight thousand users, and the prototype does not have to survive them.
• No complete error handling. The intended path works; beside it, stumbling is allowed. Edge cases cost a lot of time and rarely answer the question asked.
• No automated tests beyond the main path. A disposable piece needs no safety net for changes that will never happen.
• No accessibility audit, no legal texts, no multilingual support. All necessary for a product, all irrelevant to the question "does anyone want to use this?".

That list is the actual reason the method works economically. It lowers the price of knowing far enough that you can afford to be wrong — and a mistake noticed in week two costs a fraction of the same mistake in month eight. For the operated site afterwards, the full standard applies again, as with any premium website.

A prototype test only holds up when people are asked to complete a task rather than offer an opinion — and when nobody helps them. "What do you think of this?" produces politeness. "Book an appointment for next Tuesday" produces observations.

We invite five to eight people from the actual target group, 30 to 45 minutes each. Everyone gets the same two or three tasks, works alone and thinks aloud. We stay quiet. Four things get recorded: how many complete the task unaided, where hesitation or backtracking occurs, which words people use for what they are looking for, and what they say unprompted about the value. The third of those is underrated — it supplies the vocabulary that should later appear on the website.

Five people sounds like few, but in practice they surface the greater part of the serious usability problems: the same obstacles repeat quickly. What five people cannot answer are questions of willingness to pay or market size; those need different methods, and we say so rather than dressing an observation up as a statistic. The methodological background is in the glossary under usability testing.

A note on demand: our Google Search Console shows the query "ux prototyping services" with 110 impressions at position 5.8 — people are already searching for exactly this service, and until now there was no matching page for it here. That is one of the reasons this page exists.

A prototype for idea validation starts at CHF 10,000 excluding VAT, and it pays off whenever the alternative is an investment with an unknown outcome. The calculation is simpler than it sounds: what does it cost to build the wrong software for six months — and what does it cost to know that beforehand?

Four things are included: sharpening the assumption together with a stop criterion, a usable prototype of the two or three load-bearing flows, a test run with five to eight people from the target group, and a written recommendation with reasoning. Not included are operations, access control, scaling, maintenance and everything else on the omissions list above. The price rises when real external systems have to be connected, or when several roles with different permissions need testing.

For a sense of the orders of magnitude: a complete website sits between CHF 3,000 and CHF 25,000 with us, ongoing SEO starts at CHF 800 per month and local SEO at CHF 300 per month. A prototype is therefore not a small outlay — it is an outlay that protects a larger one. For a first bearing on your own project, use our project calculator; how website budgets are made up in Switzerland is covered under web design Switzerland.

A prototype does not pay off when the answer is already settled. If you and your team agree on what should be built and demand for it already exists, the prototype is a detour. Then the money belongs in the implementation. We say that in the first conversation too.

The part that carries gets rebuilt, not finished off — with a decided architecture, review and tests. That sounds wasteful and is the opposite: the prototype has done its job once the open questions are answered, and a rebuild with known answers goes considerably faster than the first attempt.

What the rebuild adds is exactly the list that was missing before: permission handling and sign-in, treatment of personal data under the revised Data Protection Act, automated tests across the critical paths, error handling, logging, operational monitoring, accessibility, legal texts, and measurement of load time and Core Web Vitals under real conditions. What that process looks like, and what role AI tools keep inside it, is described under AI-assisted development.

What almost never carries over from the prototype is the code. What almost always carries over is the more valuable part: the flow that proved itself, the vocabulary from the tests, and the knowledge of which feature nobody used. Larger systems we then implement as complex web solutions; if the idea turns into a calculator or configurator, our configurator and price calculator shows what a finished one looks like.

Prototyping with AI is the wrong choice when there is no open question, when the question cannot be answered by observation, or when the result is meant to go live. Those three cases account for most unhappy prototype projects.

• No open question. If it is settled what should be built and demand exists, the prototype is an expensive detour. Building directly is the faster route.
• Questions you cannot observe. Market size, willingness to pay, legal admissibility or regulatory feasibility are not answered by a prototype. Those need market research, conversations or legal advice — topics for startup consulting, not for a repository.
• Production intent from the start. If real customer data is meant to flow from day one, a prototype saves you nothing. Then it should be built properly from the start.
• No access to the target group. Without five to eight test participants the prototype stays a demo for your own screen. We settle who will test before we start — that is part of the preparation, not a footnote.
• No willingness to discard the idea. A test whose outcome is already fixed is not a test but a confirmation exercise. In that case save the money and build.

And the most uncomfortable limitation: a prototype answers "does the interaction work" and "do people understand it" very well — "will anyone pay for it" only indirectly. Confuse the two and you mistake a usability result for market evidence. We separate them cleanly in the report and write down which question is still open after the test. What we have delivered so far is in our work.