MVP Workshop: your idea turns into a clickable prototype

The usual first workshop ends with wireframes, sticky notes and minutes. Everyone nods, and three weeks later it turns out that each person understood something different. Our workshop ends with something you can actually use. Together with you we build a working prototype of your idea through AI-assisted vibe coding, and afterwards we take over the development if you want us to.

Get expert advice

Why we no longer draw wireframes

A sketch is a poor thing to argue about. It is so general that everyone reads it the way it suits them, and that is exactly why nobody in the meeting notices that two departments are talking about two different products. A real interface is an excellent thing to argue about. Anyone who clicks a button and sees the wrong screen says so straight away.

We have put that difference to use ever since language models started building in hours what used to take weeks. The workshop moves the uncomfortable questions forward, to the point where an answer still costs nothing. That is the whole trick, and it works.

What the market otherwise offers

Bootcamps and training courses: you learn how to build software with AI tools, and are then left alone with the result.
Prototype rescue: specialised consultancies take over stranded AI applications after they have fallen over in production.
Classic agency workshops: concept, wireframes, quote. The first working version arrives weeks later.

The gap in between is ours: workshop and implementation from the same team. Whoever built the prototype also knows what separates it from a product.

How the workshop runs

The standard format is one day, remote or on site with you. For bigger plans we split it across two dates, so there is time to try things out in between. What exactly gets built we settle together beforehand, because a day is enough for one idea, not for three.

Beforehand

A preliminary call of about half an hour: what is this about, who is meant to use it later, what is the core of it?
We cut the scope down. "A platform for our customers" becomes "the path from enquiry to confirmation".
Tools, data protection and rights are settled in writing before the date is fixed.

On the workshop day

We start with the process, not with the screen. Who does what, in which order, and where does it get stuck today?
Then we build. You describe, we implement, you click and say what is wrong. We repeat that round often.
Domain knowledge goes in directly. The person who does the process every day sits next to us and corrects on the spot.
At the end there is a prototype that runs. It is not pretty everywhere, but it is real.

Afterwards

You get the prototype, a short summary of the decisions and an honest list of what is still missing.
On request, an effort estimate for the production-ready implementation.
You can use it to make the case internally, apply for budget or bury the plan. That is a good outcome too.

What comes out at the end, and what does not

This belongs right at the start, because otherwise expectations break on it. The result is a validated concept in code. It is not a production system, and we do not claim that it is one.

You get

A working application that plays through the chosen process and that you can operate yourself.
The source code, which belongs to you.
The decisions of the day written down, along with the alternatives we discarded.
A sound assessment of whether the idea holds up, and what the reason is if it does not.

You do not get

Rights and roles, logging, tests, error handling. That comes with the implementation.
Resilience under load, a data protection sign-off or an operating contract.
A system you can pour real customer data into on Monday.

Why we keep going on about it: generated code looks tidy even when it holds a flaw in the reasoning. Neatly formatted, sensibly named, commented. That is exactly what makes it harder to check than badly written code, where you can see the problem. A prototype that somebody takes for finished is more dangerous than none at all.

What vibe coding is, and where it stops

Vibe coding means letting software come about mostly by describing it in plain language: you say what the program should do, a language model writes the code, you look at the result and describe the next change. The term comes from Andrej Karpathy, half as a joke, for small throwaway projects. Within a year the joke turned into a market term.

For prototypes the method is a real gain. For production it is not enough, and the line does not run between big and small but between throwaway and permanent. As soon as real data, real users and real liability are in play, the old rules apply again: read, test, understand. What we do in the workshop is to use one side of that line on purpose. What comes after it is the other side. In detail in the glossary.

Who the workshop pays off for

You have a product idea and want to know whether it holds up before a budget is applied for.
There is a spreadsheet in the house that should have been an application long ago, and nobody knows where to start.
A plan is contested internally, and everyone is discussing what they picture instead of something visible.
You need something to show the management, the board or investors, and you need it this month.
A tender or a funding application calls for a description that is more concrete than a statement of intent.

When it does not pay off we say just as plainly: if the requirements are already settled and agreed, save yourself the day and go straight into development. And if nobody in house has time to look at the prototype, the result fizzles out.

Enquire directly

Ask for a workshop date

Describe your idea in a few sentences. We will come back with an honest assessment of whether one workshop day is enough for it, and we cut the scope down together in the preliminary call.

Start your enquiry

From prototype to product

The prototype was the answer to a question, not the beginning of the product. What comes next we build again properly on that basis: data model, rights and roles, error handling, tests, the connection to the systems you already run. That has been our daily work since 2013, and it is the reason why the workshop is not a standalone product with us.

Depending on what becomes of the idea, the implementation runs as custom software development, as app development or as an extension of an application you already have. If language models are to play a permanent part in it, things carry on with AI integration.

Rights, data and tools

In the workshop your information passes through AI tools, so we settle in writing beforehand which ones those are and what they get to see. If you want to bring real data along, we talk about anonymisation first. In many cases invented sample data is perfectly enough to check the process.

The code that comes out of it belongs to you, without restriction.
Which tools and models we use is settled before the date, not after it.
We bring real personal data into play only when there is a reason for it and the legal basis is in place.
The tools for fast prototyping do not run inside the EU. If your data must not leave the building, we work with sample data in the workshop and settle the processing location for the later implementation.

Funding for getting started

There are programmes at federal and state level for consulting and digitalisation projects, and a workshop that prepares a digitalisation project regularly falls under them. Which programme fits you, what conditions come with it and whether the application is worth the effort at all, we work out in the first conversation before anyone fills in forms. More on our funding advice page.

Frequently asked questions about the MVP Workshop

What is vibe coding?

Letting software come about mostly by describing it in plain language, instead of writing it line by line. You describe the behaviour you want, a language model produces the code, you try it out and describe the next change. For prototypes that is quick and good. For software that goes into production it replaces neither architecture nor review nor responsibility.

Is the workshop result already production code?

No, and we say that plainly on purpose. What comes about on the workshop day is a validated concept in code. Missing are rights and roles, error handling, tests, logging and everything that keeps a system stable in daily use. Those things are the reason why the implementation takes longer than the prototype.

What happens after the workshop?

You decide. Some go straight into the implementation, some take the prototype into the house to make the case for it internally, and some find that the idea does not hold up in this form. That is a result too, and it is a good deal cheaper than the same insight after half a year of development.

Who owns the prototype, and what data goes into the AI tools?

The prototype belongs to you, source code included and without restriction. Which tools are used and what data they get to see, we put in writing before the date. One thing worth knowing: the tools that make fast prototyping possible in the first place process outside the EU. So in the workshop we work with invented sample data, which is almost always enough for the process. Where your real data gets processed later is your decision at the implementation stage, and models inside the EU or in your own environment are available there.

How long does the workshop take?

The standard format is one day. For more extensive plans we split it across two dates, so you can work with the interim state in between. On top of that there is a short preliminary call in which we cut the scope down.

Who from your side should be there?

At least one person who really knows the process, and one who is allowed to decide. More than a handful of people makes the day heavy going. Nobody needs technical background knowledge, that part is ours.

Can we develop the prototype further ourselves?

Yes, the code belongs to you. If you have a development team, that is a realistic route. The one thing that matters is treating the state of it for what it is: a basis for the new build, not the half-finished first part of it.

What does the workshop cost?

The price depends on the format and on whether we work remotely or on site. In the free first conversation we cut the scope down and you get a written quote before anything is commissioned.

Ready for your KI project?

Tell us about your project. We'll get back to you promptly with an honest assessment.