A first product version that real customers can use

You have an idea for a product. Maybe a platform where your customers track their own orders, maybe an app next to the device you already sell. The idea sits in a presentation and now you want it built. The risk is that you build for a year on something you discover on the first day customers want just a little differently. An MVP is the smallest version customers can really use, so you discover that in the first weeks instead of after a year.

Why an MVP and not the whole product at once

Building a full product before anyone has used it is gambling with a big stake. Every feature you put in is an assumption: that customers want it, that they want it that way, that they will pay for it. The more assumptions you build at once, the longer it takes before you know which ones hold. An MVP turns that around. We choose the one core that makes the product worthwhile and build it well enough to give to real customers. Everything around it waits until those customers ask for it.

That is not a cheap version of the real product. It is the real product, in its first form. It has to work, be secure, and you have to be able to put a customer on it without embarrassment. The difference is in what we leave out, not in how carefully we build what goes in.

What goes into the first version and what does not

The first question in the intake is not what the product should all be able to do, but what a customer would use it for on day one. Then we make two lists. On one is what is needed to finish that one task from start to end: logging in, the core task itself, a way to order or pay if that belongs to it. On the other is everything that is nice but can wait: reports, integrations with ten packages, an admin screen with filters for everything. We do not throw the second list away. It is the basis for what you build after the first customers have shown what they really use.

If you are not sure yet whether the idea holds, Product feasibility is the better first step. There we test the assumptions before a line of code exists. If the idea is already clear, it often starts with our Prototype in 10 business days, and that prototype grows on into the MVP.

From prototype to something customers use

A prototype shows that something can be done. An MVP has to keep working every day while people you do not know click on it. That asks for things a prototype does not need: accounts and passwords that are right, a database with backups, error messages that say something, an environment where you can put a new version without breaking the previous one. We build that in the weeks after the prototype, in a fixed order: first what makes the product secure, then what makes it usable, then what makes it attractive. If the screen itself is the core of the product, we team up with UX and UI design, so the first customers do not drop off on a button they cannot find.

During the build you sit at the table every week. Not to read a report, but to click through the newest version and say what feels wrong. The software runs in a European cloud, the data stays in the EU, and we arrange the processing of personal data properly from the first version.

After the first customers: build on, adjust, or stop

As soon as the first customers use the product, the information you did it for comes in. Which feature they open every day, where they get stuck, what they email to ask. We build that measurement in from the start, so it is not a feeling but a list. On that basis you decide: build on along the second list, adjust the core because customers use it differently than expected, or stop because the demand turns out not to be there. That last one is the cheapest outcome there is, and if we see it coming we tell you right away.

Whatever you decide, the product is yours. Source code, database, documentation, and the environment it runs on are in your name. You can carry on with us, with another team, or with your own people. If the product becomes a device that has to go into the factory, we take the next step with Prototype to production. If it stays software, Technical product launch helps with the step from ten customers to two hundred.