MVP (Minimum Viable Product).

The term comes from the lean startup movement and is routinely misused. An MVP is not a stripped-down version of the desired product with something missing everywhere; it is a complete solution for one single, narrowly cut use case. The question is not 'what can we leave out?' but 'which one workflow has to work end to end for someone to open the tool voluntarily a second time?'. Everything that does not carry that workflow — roles, reporting, multilingualism, design polish — is deliberately deferred. That discipline separates an MVP from an unfinished product nobody takes seriously.

An MVP is a measuring instrument, not a milestone. Before it is built, you define which observation supports the idea and which refutes it: how many of the invited people complete the workflow, how many come back after a week, how often the old way gets chosen anyway. Without that definition set in advance, every result is interpreted favourably in hindsight. Who tests also matters: colleagues and friends are polite, affected or paying users are honest. An MVP only ever demonstrated internally produces applause instead of insight.

A practical example: a service business wants to replace a quoting process that currently runs on Excel and email. The MVP is not 'a CRM' but exactly one workflow — capture the enquiry, generate the quote from text blocks, send it as a PDF, set the status to won or lost. No permissions system, no accounting interface, no reporting. Three employees work with nothing else for four weeks. If all three stay with it voluntarily and stop opening Excel, expansion is justified. If the opposite happens, a few weeks were spent rather than half a year.

With us, a prototype or MVP for validating an idea starts at CHF 10,000; a fully built product sits well above that. The figure is deliberately meant as a boundary: anyone spending a multiple of it on the first answer to 'does anyone actually want this?' is usually buying features rather than insight. And not every idea needs bespoke software. If the workflow can be covered by an existing standard product, a spreadsheet or a deliberately manual process, that is the faster and cheaper test. Custom development pays off where no standard tool fits the workflow cleanly.