Keep your product working for years after launch

Your product has launched, the first customers are working with it, and the team is already busy with the next thing. Then the supplier calls: the processor in your device is going out of production. Or a customer reports that the app no longer opens after an update of their phone. A product that is on the market does not stand still, and nobody had reserved time for that.

Why a product keeps asking for attention after the launch

The launch feels like the finish, but for the product it is the start. From that moment everything around it changes. Operating systems get updates, a library in your firmware gets a security hole, a supplier discontinues a sensor, and rules like NIS2 set requirements for how you handle updates and notifications. The product itself does not change along. You usually only notice that when a customer calls.

We take over that attention. Not as a thick maintenance contract with a list of exclusions, but as a fixed rhythm: we know what is in your product, we track what changes around the product, and we plan interventions before they become an outage. That can start right after a Technical product launch, but just as well with a product that has been on the market for years and that nobody has ever looked after.

Parts and software with an expiration date

Every product is a stack of dependencies. A circuit board with thirty components, firmware that leans on someone else's library, an app that has to run on the newest version of iOS and Android, a cloud integration with a party that can change its API. Each of those parts has an end date, and the supplier decides when it falls, not you.

We start with an inventory: what exactly is in it, who it comes from, and how long it remains available or supported. A calendar rolls out of that. A chip that goes out of production in a year and a half is still a calm decision now: choose a replacement, test it, and place the last order. The same chip that is no longer available next month is a production stop. If the inventory shows a part is already unavailable now, we tell you right away.

Updates your customers do not notice

A well-maintained product does not stand out. The firmware gets a security update without the customer having to send the device back. The app keeps working after the yearly update of the operating system. A replaced sensor delivers the same readings as the old one. That asks for a way to roll out updates, for a test setup with the old and the new version side by side, and for someone who keeps an eye on the suppliers and their changes.

We set up that rhythm and run it. Every quarter you get an overview: what has changed, what we have updated, and what is coming in the next months. If an intervention becomes too big for an update, for instance a new design of the circuit board, we take that up through Prototype to production. If you sell the product under another brand to partners, their versions run along in the same rhythm through White-label products, so nobody falls behind.

Stopping properly when the product is done

Every product stops at some point. Because there is a successor, because the market has shifted, or because the parts are no longer available. A product that just disappears costs trust: customers with a device that suddenly no longer talks to the app, an online store still taking orders for something that is no longer delivered, data nobody knows the location of anymore.

We plan the end just like the rest. A last production batch or last order of parts, a date until which updates and spare parts remain available, a message to customers that comes in time, and a plan for the data the product has collected. If there is a successor, we make sure existing customers can move to it without hassle. Everything we have recorded in the meantime is yours: the inventory, the test setup, and the documentation. You are the owner, even if you ever place the management elsewhere.