From prototype to a product that runs every day

The prototype works. You showed it to a few clients, they were enthusiastic, and now they want to use it. But it runs on the developer's laptop, the passwords are in the code, and when something breaks, only that one person knows how to fix it. That is not a product. It is a demo that has not fallen over yet.

Why a prototype is not yet a product

A prototype is built to prove something: that the idea works, that the calculation is right, that the connection to Exact or AFAS (two Dutch accounting packages) succeeds. Everything that does not contribute to that is left out on purpose. No error handling, no backups, no login management, no tests. That is the right call, because it gets you something to show in ten business days. The problem starts when the prototype quietly becomes the product. Every new client raises the risk, and every failure costs more than the last.

Making it production-ready is the work you do not see when everything goes well. It makes sure a wrong input gives a clear message instead of a blank screen, that the data of client A never ends up with client B, and that a failure at three in the morning triggers an alert instead of an angry email the next day. It is less exciting than building the prototype, and it is exactly the difference between something that works and something you can sell.

What the production-ready version adds

We start by reading. We go through the prototype's code, even if another company built it, and list what is missing. We rank that list: what must be there before the first paying client uses it, and what can wait until there are twenty. That way you see in advance where the work will go, and you choose where to draw the line.

Then we build the missing parts. Usually that means automated tests, so a change does not quietly break something else. A repeatable release, so putting a new version live is one step and not an evening of working through a checklist. Security: login, permissions per client, encrypted storage, and no more secrets in the code. Monitoring that alerts you when the application slows down or goes offline. And an environment in a European cloud that grows with the number of users. If the product is a device with firmware, there also has to be a safe way to update that firmware once the device is at the client.

First clients first, then the rest

We do not switch everything over at once. Once the basics are in place, a first group of real users starts working with the product. We watch the monitoring and see what they do differently than expected: which input we did not foresee, where it gets slow, which message nobody understands. We fix what we find before the next group joins. That way the product grows in steps you can follow, and your first client does not become the test subject for everything that comes after.

The screens and flow users see can still change in this phase. If that first group shows people getting stuck on a step, we handle it together with UX and UI design instead of writing a help text around it.

Your team can take it from there

The goal is not for you to keep needing us. At the end, you get the source code, the infrastructure configuration, and documentation that explains how it fits together and how to roll out a new version. We walk through it with the people who will maintain it, whether that is your own developer or a company you hire later. You are the owner, and the data stays within the EU.

If you would still rather hand off the daily management, you can do that through Software maintenance. And if your product grows from ten clients to a thousand, the foundation is there, so the Technical product launch brings no surprises. Not sure whether your prototype is ready yet? We find out in the free intake, and if it is too early, we tell you right away.