Van prototype naar een product dat elke dag draait

Het prototype werkt. Je hebt het laten zien aan een paar klanten, ze waren enthousiast en nu willen ze het gebruiken. Maar het draait op de laptop van de ontwikkelaar, de wachtwoorden staan in de code en als er iets kapotgaat, weet alleen die ene persoon hoe het te repareren is. Dat is geen product, dat is een demo die toevallig nog niet is omgevallen.

Waarom een prototype nog geen product is

Een prototype is gebouwd om iets te bewijzen: dat het idee werkt, dat de rekenstap klopt, dat de koppeling met Exact of AFAS lukt. Alles wat daar niet aan bijdraagt, is bewust weggelaten. Geen foutafhandeling, geen back-ups, geen inlogbeheer, geen tests. Dat is terecht, want zo kom je in tien werkdagen tot iets wat je kunt laten zien. Het probleem begint als dat prototype stilletjes het product wordt. Elke nieuwe klant maakt het risico groter, en elke storing kost meer dan de vorige.

Productierijp maken is het werk dat je niet ziet als alles goed gaat. Het is wat ervoor zorgt dat een verkeerde invoer een nette melding geeft in plaats van een leeg scherm, dat de data van klant A nooit bij klant B terechtkomt, en dat een storing om drie uur 's nachts een bericht geeft in plaats van een boze mail de volgende ochtend. Minder spannend dan het prototype bouwen, maar precies het verschil tussen iets wat werkt en iets wat je kunt verkopen.

Wat er in de productierijpe versie bij komt

We beginnen met lezen. We nemen de code van het prototype door, ook als een andere partij het heeft gebouwd, en maken een lijst van wat er ontbreekt. Die lijst zetten we op volgorde: wat moet er zijn voordat de eerste betalende klant erop werkt, en wat kan wachten tot er twintig zijn. Zo zie je vooraf waar het werk in gaat zitten en kies je zelf waar de grens ligt.

Daarna bouwen we de delen die ontbreken. Meestal zijn dat automatische tests, zodat een aanpassing niet onopgemerkt iets anders stukmaakt. Een herhaalbare release, zodat een nieuwe versie live zetten één handeling is en geen avond met kruisjes op een checklist. Beveiliging: inloggen, rechten per klant, versleutelde opslag, geen geheimen meer in de code. Monitoring die meldt als de applicatie traag wordt of uitvalt. En een omgeving in een Europese cloud die meegroeit met het aantal gebruikers. Gaat het om een apparaat met firmware, dan hoort daar ook een manier bij om die firmware veilig bij te werken zodra het apparaat bij de klant staat.

Eerst de eerste klanten, daarna de rest

We zetten niet alles in één keer om. Zodra de basis staat, laat je een eerste groep echte gebruikers op het product werken. Wij kijken mee op de monitoring en zien wat ze anders doen dan verwacht: welke invoer we niet hadden voorzien, waar het traag wordt, welke melding niemand begrijpt. Wat we daar vinden, lossen we op voordat de volgende groep erbij komt. Zo groeit het product in stappen die je zelf kunt bijhouden, en blijft de eerste klant niet de proefkonijn van alles wat daarna komt.

Het scherm en de flow die gebruikers zien, kunnen in deze fase nog schuiven. Blijkt uit die eerste groep dat mensen vastlopen op een stap, dan pakken we dat samen op met UX- & UI-design in plaats van er een uitlegtekst omheen te schrijven.

Je team kan het daarna zelf

Het doel is niet dat je ons nodig blijft hebben. Aan het eind krijg je de broncode, de configuratie van de infrastructuur en documentatie die uitlegt hoe het in elkaar zit en hoe je een nieuwe versie uitrolt. We lopen dat door met de mensen die het gaan onderhouden, of dat nu je eigen ontwikkelaar is of een partij die je later inhuurt. Je bent de eigenaar, en de data blijft binnen de EU.

Wil je het dagelijks beheer toch liever uit handen geven, dan kan dat via Beheer & onderhoud. En gaat je product straks van tien naar duizend klanten, dan staat er een fundament waarop de Technische lancering geen verrassingen oplevert. Weet je niet zeker of je prototype al zover is? Dat zien we in de gratis intake, en als het nog te vroeg is, vertellen we je dat direct.