Launch your product without turning launch day into a crisis

The product is ready. The prototype has been developed further, the last comments from the test group have been processed, and everyone wants to go live. And then it turns out live is not a button. There is no domain, no production environment, nobody knows who gets called if it stops at 3 AM, and the only one who can roll out a new version is the developer who just went on vacation. The technical launch is the work that sits between a working version and a product with real users.

Why a working version is not yet a product

During the build everything runs in one place: the developer's laptop, or a test server three people look at. That is fine for building and testing. It is not enough to let customers work on. A test environment falls over at twenty simultaneous users, has no backup from yesterday, and tells nobody when an integration stops. You only notice that on the day it matters.

We tackle that difference. We go through what is there now and make a list of what is missing: hosting, domain and certificates, a separate production database, backups, monitoring, a way to roll out a new version and roll it back again. Usually that list is shorter than you fear, sometimes longer. In both cases we tell you right away, with what it costs in days. If you come out of our Prototype to production project, part of this is already done and we start further down the list.

What has to be ready before the first customer logs in

We set up the production environment in a European cloud, separate from the environment your team builds and tests in. A bug in a new version then does not touch the customers working on the old version. The database gets automatic backups, and we test those backups by really restoring one. A backup you have never restored is an assumption, not a backup.

Then comes the monitoring. If the product gets slow, an integration with your accounting package drops out, or a user runs into an error message, you want to know before your customer does. We set it up so that such alerts reach a person, not a mailbox nobody reads. Finally we test under load: we send more traffic at the product than you expect in the first weeks and see where it starts to creak. Better now than with customers on it.

Launch day itself

A launch is not a moment but a checklist. We write it together with you: what happens in which order, who does what, when the domain switches, how the first users are invited, and at which point we decide to roll back. That rollback we practice in advance on the production environment, so it is not theory when it turns out to be needed.

On the day itself we are there. Not because we expect it to go wrong, but because the first hours with real users always show something no test has found. A form that does not quite fit on an old tablet, a confirmation email that lands in spam, an export that takes twenty minutes instead of two. Small things you would rather fix the same afternoon than pull out of complaints next week. Often we start with a limited group, one customer or one department, and only switch on the rest once that group has worked for a few days without surprises.

After the launch it is yours

The environment, the configuration, and the documentation are yours. You get a handover document that states how it runs, where the backups are, how you roll out a new version, and whom you call for which alert. Your team can carry on with that themselves, or you leave the management to us. That is a choice you can still change later, not one you lock in at the launch.

A product that is live keeps changing. New versions come, parts age, and one day it is replaced or switched off. How you arrange that properly, from the first update to the last user, is the work of Product lifecycle management. If you will sell the product under another company's name, we set up the launch so that White-label products does not require a second launch. Everything starts with a free intake, in which we look at what is there and what still has to happen.