Build a prototype and validate the idea.

A validation prototype is the smallest working version of a product idea that lets real users complete a real task from end to end, and it tests exactly one assumption the whole business case depends on. It is not a draft. It is software that runs: with a database, a sign-in and, where willingness to pay is the question, a connected payment.

The boundary below matters. A wireframe or a clickable mock-up in a design tool shows screens and flows. That lets you check whether people understand an interaction, which is genuinely useful. But a mock-up stores nothing, processes nothing and takes no money. It answers "can this be used", not "is this worth anything". Which is exactly why so many ideas survive the design phase and only fail after expensive development.

The boundary above matters just as much. An MVP in the original sense is already a sellable product: a small feature set, but complete enough to run, support and develop over time. A validation prototype is allowed to be worse than that. It may cover a single use case, have gaps at the edges, and be switched off once the test run ends. What such a build already includes and what it still lacks is set out in more detail in our guide to MVP development.

In practice the difference comes down to the question you want answered. "Do people understand the interface?" is answered cheaply by usability testing on a mock-up. "Will people pay for it?" is answered only by something that can take money. We build the second. If the first conversation makes clear that your open question is really the first one, we say so — and then you do not need a CHF 10,000 prototype.

CHF 10,000 buys one use case from end to end: a landing screen, sign-in, the one core function, real data storage, a connected payment where needed — and the measurement setup without which the whole test would be worthless. Nothing more. Anything added displaces something else.

For a sense of scale: Swiss suppliers price software development at roughly CHF 150 to 250 an hour. That is a market figure taken from published rate overviews of Swiss development firms, not a quote from us. On that basis CHF 10,000 buys around 40 to 65 working hours. That is not much. A prototype works because things are ruthlessly left out, not because anyone types faster. Once you know that number, the short list below explains itself.

Included

• One use case, played through completely. From the first screen to the result that actually delivers the value — not to a placeholder saying "coming soon".
• Real data storage. What users enter is saved and can be analysed. Without that, depth of use cannot be measured.
• Sign-in and identification. Return visits can only be counted if users can be recognised.
• Payment, where willingness to pay is the open question. A connected card or TWINT payment — the gap between "I would buy that" and "has bought" is the entire point.
• Measurement setup. Events rather than page views, defined along the signals you agreed in advance, including the privacy-compliant implementation.
• Hosting setup and handover. The prototype runs on your domain, on your accounts, with your code.

Not included

• Roles and permissions. Admin, team lead, finance, guest access: every extra role multiplies the cases that have to be tested. A prototype has one kind of user.
• Multiple languages. One language. In Switzerland that means deciding up front whether you test in German or French — running both roughly doubles the content and support effort.
• Data migration and interfaces to existing systems. The single most expensive line item in almost any software project, and almost always irrelevant to the validation question.
• Native iOS and Android apps. A prototype runs in the browser. The detour through the app stores costs weeks before the first user sees anything.
• A worked-out corporate design. The prototype looks clean and credible, but it is not brand work. A design system belongs to the phase after validation.
• The advertising budget. The most important item on this list: the prototype brings no users with it. If your test users come from paid ads, plan a separate four-figure budget.

If your venture genuinely needs several of these points before it can be tested at all, it is not a case for a prototype at this scale. Then we are talking about a project, and about the price ranges we publish under software development costs in Switzerland.

The step from prototype to full product costs a multiple, because past that line the budget is no longer driven by the core function but by everything demanded around it. The function itself is often the smallest item on the invoice.

These are the blocks that make the difference, roughly in order of weight:

• Roles, permissions and tenants. As soon as several user types see and may do different things, the number of combinations that have to be built and tested grows disproportionately.
• Edge cases and failures. The prototype covers the expected path. A product has to handle abandoned payments, duplicate records, lost passwords, refunds and network outages.
• Integrations. Accounting, ERP, CRM, shipping, calendars, identity providers. Every interface is its own small project with someone else's documentation and someone else's schedule.
• Migrating existing data. Old data is incomplete, contradictory and stored in formats nobody documented. This item is underestimated in quotes with striking regularity.
• Data protection and compliance. For Swiss applications, at minimum the revised Federal Act on Data Protection: a record of processing activities, a deletion policy, data processing agreements, server location. Sensitive personal data adds considerably more.
• Test coverage and operations. Automated tests, monitoring, backups, recovery, dependency updates. For running costs after launch, Swiss suppliers commonly quote an order of magnitude of around 15 per cent of the development effort per year — again a market figure, not a promise from us.
• Support and training. From the first paying customer onwards there are expectations about response times. Those expectations cost money, whoever meets them.

As a market frame for Switzerland, published price overviews from Swiss development firms give roughly the following for 2026: internal tools and dashboards CHF 30,000 to 60,000, business web applications CHF 60,000 to 120,000, platforms CHF 80,000 to 300,000. Again: third-party market figures, not a quote. Our own binding prices are further down this page and on web design prices.

Which is why the decisive sentence of this page belongs here: those amounts are not wrong. For a finished product they are appropriate. What is wrong is the moment you spend them — namely before anyone has shown that the product is needed.

Validated means people you do not know, and who owe you nothing, do something of their own accord that costs them money, time or data. Everything else is mood. Four groups of signals can carry a decision, and they differ in how easily they can be faked.

1. Qualified sign-up

Not "left an email address", but "left an email address and then did something". A sign-up followed by no action at all measures how attractive your headline was, not your product. The signal becomes meaningful when the sign-up carries a small hurdle: a note on the intended use, a business address, a chosen appointment.

2. Willingness to pay

The hardest signal there is, and the only one that genuinely answers the pricing question. It comes in grades: a real payment beats a pre-order with a deposit, which beats a stored card that is never charged, and all three beat any survey. In practice the question "would you pay CHF 49 a month for this?" has almost no predictive value — the answer costs nothing.

3. Depth of use

How many of the people who signed up actually finish the core task? That one number separates curiosity from usefulness. What counts is completion, not entry: someone who gets halfway through and stops has told you something important — usually that at exactly that point the effort outweighs the expected gain. The basics are explained in our glossary entry on conversion rate.

4. Return visits

Do users come back on their own after two and after four weeks, without a reminder email? For anything meant to be used regularly, that is the single most important number. For one-off applications — a tax return, a move, a sale — return visits are the wrong measure; there, referrals take their place.

What matters is when the threshold is fixed. Before the first day of development we write down which number counts as confirmation and which as refutation. One example of such a threshold, deliberately an example rather than an industry benchmark: "Of 100 people who open the prototype, at least 30 complete the core task and at least 8 pay." Whether 30 and 8 are the right numbers for your venture depends on your contribution margin per customer, which we work through together beforehand. Define the threshold after the test and any data set will confirm what you hoped for.

Praise, reach and statements of intent prove nothing, because they cost the people giving them nothing. They feel good, and they are the most common reason products get built anyway. This list is uncomfortable, which is why it appears here in full.

• Approval from people you know. Friends, family and your own network answer a different question from "do I need this" — namely "do I like this person". Their feedback is useful for usability and worthless for demand.
• Statements of intent without commitment. A non-binding letter of interest from a company costs the person signing it nothing and binds nobody. A pre-contract with a deposit is an entirely different thing.
• Surveys about hypothetical prices. People systematically misjudge their own future behaviour. That is not dishonesty but a well-documented pattern — and the reason we test prices with a checkout page rather than a questionnaire.
• Clicks and reach on their own. Page views, impressions, time on page and bounce rate measure the pull of your advertising. They say nothing about whether the product behind it is useful. A viral post and a viable business have little to do with each other.
• Newsletter sign-ups with no follow-up action. A waiting list is a start, not proof. It only becomes a signal once the list does something — replies, books, pays.
• Investor interest. Investors assess market, team and narrative. Their commitment is a bet on you, not evidence of demand. Funded products without customers exist in quantity.
• Competitors doing the same thing. That someone else offers the same thing proves someone else thinks it is a good idea. Whether they make money from it is not visible from outside.

It is worth going through this list before you start and honestly ticking off what your confidence has rested on so far. If only items from this list remain, the prototype is exactly the right next thing to spend money on.

A validation prototype is the wrong method when the market demands a licence, a physical device or a critical mass before the first real user appears. In these four situations a quick test does not measure the risk your venture actually carries.

Regulated activities

Anyone accepting public deposits on a commercial basis needs a licence in Switzerland. The so-called sandbox rule allows deposits up to a threshold of one million francs without a licence, subject to conditions — among them that depositors must be told in advance that there is no FINMA supervision and no deposit protection. Similarly, software that diagnoses or treats can qualify as a medical device and then falls under the corresponding conformity assessment. And applications handling health, biometric or criminal data process sensitive personal data under the revised Data Protection Act. In all of these cases the first expense is legal advice, not technical work. We are not a law firm, and we say so in the first conversation rather than selling a prototype that could not go live as designed.

Hardware dependency

If your product is a physical object plus an app, the risk almost never sits in the app. It sits in unit cost, certification, lead times and returns. A software prototype can test demand for the promise — it cannot prove that the device can be manufactured at a price that leaves a margin. Confuse the two and you validate the wrong half of the business.

Network effects

Marketplaces, brokerage platforms and communities only create value once both sides are present in sufficient density. A prototype with fifty users then measures the emptiness rather than the idea. The way out is to narrow the field: one city, one industry, one building, one association. If the value cannot be shown in a slice that small, the prototype still works as a method — just not at the breadth the product is eventually meant to reach. If no sensible slice exists, a prototype is the wrong expense.

Very long procurement cycles

Selling to large enterprises and to the public sector, many months often pass between first contact and signature. An eight-week test measures, at best, willingness to attend a meeting. In that setting a paid pilot with a single customer makes more sense: it costs more than a prototype, but it produces a signal on the same timescale as the decision itself.

And a fifth case

If you are going to build the product regardless of the result — for strategic reasons, because of a contractual commitment, or out of conviction — save yourself the test. A measurement that cannot change a decision is an expense without a return. In that case let us talk about building it; how we do that is set out under complex web solutions.

Four to eight weeks pass between the first session and the first real user, followed by a test run of two to six weeks. The process has five steps, and the first one matters most.

1. Assumption and stopping rule (week 0, half a day). We write down in two sentences which assumption is being tested, and in two numbers what counts as confirmation and what as refutation. Both sides sign that document. Without this step the prototype gets talked up at the end.
2. Cutting the scope (week 1). We break the idea down to the one use case that carries the assumption, and visibly strike out everything else. The output is a flow diagram, a list of screens and a decision on which data is collected.
3. Building (weeks 2 to 5). Development in weekly increments you can use yourself. No presentations, just access. The measurement setup is built alongside, not afterwards.
4. Launch (weeks 5 to 6). The prototype goes live on your domain, with an imprint, a privacy notice and the required consent banner. At the same time you start bringing test users in — through ads, direct outreach, an association, an existing list. Anyone who has not prepared this loses weeks here.
5. Test run and analysis (weeks 6 to 10). Two to six weeks of real use, accompanied by five to ten conversations with people who dropped out. Those who abandoned tell you more than those who were satisfied. At the end there is a report against the thresholds agreed in advance — and a recommendation that is allowed to read "stop".

What most often breaks the schedule in practice is not development. It is decisions left open on the client side and a missing route to the target audience. We check both before the contract starts, because neither raises the price but both can ruin the result. If you also need a landing page to drive traffic, that is a separate, small item — see landing pages.

Three outcomes are possible — keep building, rebuild or stop — and all three are a success, because all three enable a decision that could not be made before. Only one of them leads straight to a large follow-on project, and that is fine.

Keep building

The thresholds are met and willingness to pay is proven. Now is the time for the items deliberately missing from the prototype: roles, edge cases, integrations, operations. The prototype is rarely the foundation of the product — it is the foundation of the requirements. What you take with you is a specification based on observed behaviour rather than assumptions. That is why a follow-on project after validation usually costs less than the same project without it.

Rebuild

The most common outcome. The core idea holds, but not in the way you expected: a different audience responds, a side feature gets used more than the main one, or the price needs to be three times different. The assumption is then rewritten and tested a second time on the same setup. That costs a fraction of the first round, because measurement, access and infrastructure are already in place.

Stop

The thresholds are missed by a clear margin, and the conversations with the people who dropped out explain why. Then the venture ends. This is the outcome supplier pages never write about, and it is economically the most valuable of the three: you have spent roughly CHF 10,000 instead of CHF 50,000 to 100,000. The difference of CHF 40,000 to 90,000 is not saved in the sense of put aside — it is available for the next venture, instead of disappearing into the maintenance and support of a product nobody uses.

What remains in all three cases: the code and every access credential, the analysis, the notes from the user interviews, and the list of interested people you reached. None of it belongs to us.

We build validation prototypes from our studio at Gustav-Maurer-Strasse 23 in 8702 Zollikon, with our own development team and no intermediaries. In Zollikon, Küsnacht, Zurich and the immediately neighbouring municipalities we also work on site; for engagements elsewhere in Switzerland, scoping and progress reviews run through fixed video sessions.

Honesty includes saying what we are not. We are not a product studio that has taken twenty funded start-ups to market. Our publicly visible work consists of websites, brand and e-commerce projects for Swiss SMEs, plus a web application that maps the workflow of a tax advisory practice from enquiry to booked appointment. If you are looking for a team that does nothing but product validation, better addresses exist — and we would rather tell you that in the first conversation than in the third month.

What we do bring: we build the things ourselves. Scoping, development, measurement and analysis sit in the same small team, which is the reason a working prototype at CHF 10,000 is possible at all. And we understand the traffic side: no users, no test, and users come from ads, search or direct outreach — subjects we work on daily anyway.

If your question sits before the prototype — business model, market entry, the order of the next steps — our start-up consulting is the better starting point. If it sits after it, because demand is long since proven and only scope and price are open, you will find the ranges under software costs in Switzerland and web design prices. Our project calculator also gives a first rough estimate for your venture.

Our binding entry prices

• Prototype for validating an idea: from CHF 10,000 — one use case, real users, real payment, measurement setup, four to eight weeks.
• Website and web application: CHF 3,000 to 25,000 — depending on scope, from a single landing page to a multilingual company site with bespoke tools.

All amounts exclude VAT. The price becomes binding after the scoping session, because before that nobody can say seriously what is being built.