Software productieklaar maken na een MVP

Software productieklaar maken na een MVP

software productieklaar maken | MVP doorontwikkelen | van prototype naar product

Het werkt in de demo. Dat is iets anders dan klaar

Er staat iets. Je kunt het laten zien, mensen worden enthousiast, misschien heb je al een paar gebruikers. En dan komt het moment dat er echt klanten op moeten, met hun gegevens en hun geld. Dat is precies het punt waarop de meeste MVP's kraken.

Niet omdat er slecht werk is geleverd. Een MVP is bedoeld om snel te toetsen of iemand je product wil, en daarvoor mag je bewust dingen overslaan. Het probleem ontstaat wanneer die overgeslagen dingen nooit meer worden ingehaald en het prototype stilzwijgend het product wordt. Op deze pagina staat wat er dan alsnog moet gebeuren, wat dat kost en hoe je bepaalt of doorbouwen nog verstandig is.

Wat betekent productieklaar precies?

De kern van het verschil zit in wat er gebeurt als iets misgaat. In een demo mag een foutmelding op het scherm verschijnen, want jij bent de enige die kijkt. In productie moet die fout worden opgevangen, ergens vastgelegd en bij jou terechtkomen, terwijl de gebruiker een nette melding ziet en verder kan.

Zeven signalen dat je er nog niet klaar voor bent

Herken je er drie of meer, dan is doorlichten verstandiger dan doorbouwen.

• Er is geen tweede persoon die de code ooit heeft bekeken.
• Je weet niet waar de gegevens staan, of wie er bij kan.
• Er zijn geen back-ups, of er is nooit getest of terugzetten werkt.
• Een wijziging doorvoeren voelt spannend, want je weet niet wat er stukgaat.
• Fouten merk je pas als een gebruiker je belt.
• Het is nooit getest met meer dan een handvol gebruikers tegelijk.
• Er is geen documentatie, en de bouwer is de enige die weet hoe het in elkaar zit.

Dat laatste punt is het gevaarlijkste, want het is ook het punt waarop je nergens meer heen kunt. Vertrekt die persoon, dan begint de volgende opnieuw.

De checklist met wat er moet gebeuren voordat je opengaat

Beveiliging en toegang

Wie mag wat zien, en klopt dat ook als iemand het probeert te omzeilen? Bij software met meerdere klanten is dit het belangrijkste punt van allemaal, want gegevens van de een mogen op geen enkele manier bij de ander terechtkomen. Daarnaast horen wachtwoorden versleuteld opgeslagen te zijn en moeten sleutels van externe diensten niet in de code staan.

De database

In een MVP wordt de datastructuur vaak gaandeweg bedacht. Dat werkt tot je gaat groeien, en dan wordt elke zoekopdracht traag of blijkt een veld verkeerd opgezet. Dit is het onderdeel dat het duurst is om later te veranderen, want alle bestaande gegevens moeten mee.

Fouten opvangen en zien

Er moet ergens vastgelegd worden wat er misgaat, en jij moet dat te zien krijgen zonder dat een klant je belt. Een gebruiker hoort een nette melding te krijgen in plaats van een wit scherm of een technische foutcode.

Back-ups die werken

Een back-up die nooit is teruggezet, is geen back-up maar een aanname. Er hoort automatisch een kopie gemaakt te worden, bewaard op een andere plek, en iemand moet een keer geoefend hebben of terugzetten daadwerkelijk lukt.

Tests op de dingen die geld raken

Alles testen is voor de meeste producten overdreven. De onderdelen waar geld of gegevens in omgaan wel, dus inloggen, betalen, rechten en de kernfunctie. Zonder die tests durf je op termijn niets meer te veranderen, en dan staat je product stil.

Snelheid onder druk

Met tien gebruikers is bijna alles snel genoeg. Met duizend records in een tabel gedraagt hetzelfde scherm zich anders. Voor livegang toetsen we hoe het systeem zich houdt bij realistische aantallen, niet bij testdata van vijf regels.

Updates zonder stilstand

Een nieuwe versie hoort met een druk op de knop live te gaan, en terug te kunnen als er iets niet klopt. Zolang dat handmatig gebeurt, is elke update een risico en durft niemand meer iets aan te passen.

Privacy en verwerking

Zodra je persoonsgegevens van anderen verwerkt, hoort vast te liggen welke gegevens dat zijn, waar ze staan, hoe lang je ze bewaart en hoe iemand ze kan laten verwijderen. Dat is deels techniek en deels papierwerk, en het is makkelijker om het nu in te bouwen dan straks.

Doorbouwen of herbouwen?

De vraag die iedereen stelt, en waar wij pas antwoord op geven nadat we de code hebben bekeken. Een eerlijke inschatting kun je niet maken op basis van een gesprek.

Doorbouwen ligt voor de hand wanneer de datastructuur logisch in elkaar zit, de code enigszins geordend is en de problemen vooral in randzaken zitten zoals beveiliging, tests en foutafhandeling. Dan repareer je gericht en gaat het geld naar verbeteringen die je ziet.

Herbouwen is goedkoper wanneer het datamodel niet klopt of wanneer de applicatie met AI of no-code is samengesteld zonder dat iemand de structuur heeft bewaakt. In die gevallen kost elke aanpassing meer dan opnieuw beginnen, en blijf je fouten repareren die uit dezelfde bron komen. Daar hebben we een aparte pagina over, vibe coded app laten herbouwen.

In de praktijk is het vaak geen keuze tussen twee uitersten. Regelmatig behouden we de voorkant en bouwen we de achterkant opnieuw, of andersom.

Zo pakken wij het aan

• Doorlichten. Een senior bekijkt de broncode, het datamodel, de beveiliging, de hosting en de documentatie. Je krijgt een overzicht van wat goed zit, welke risico's er zijn en wat eerst moet.
• Prioriteren. Niet alles hoeft voor livegang. We splitsen in wat blokkerend is, wat kort daarna kan en wat kan wachten tot je weet dat het gebruikt wordt.
• Repareren in fases. Je betaalt per afgeronde fase en volgt de voortgang live mee. Bij grotere ingrepen komt er eerst een UI/UX-ontwerp waar jij akkoord op geeft.
• Overdragen. Documentatie, toegang tot alle accounts en de broncode op jouw naam. Ook als je daarna met iemand anders verdergaat.

Hoe een traject bij ons van intake tot oplevering loopt, staat op onze werkwijze.

Wat het kost

Doorontwikkelen van bestaande software begint bij ons rond € 2.500 voor doorlichten en gericht verbeteren. Moet er substantieel herbouwd worden, dan zit je meestal tussen € 8.500 en € 18.500, afhankelijk van hoeveel er behouden kan blijven. Wij factureren met 0% btw.

Loopt het werk door, dan is capaciteit inhuren vaak logischer dan een vaste projectprijs. Dat kan vanaf € 1.000 per 4 weken voor een dag in de week. De volledige opbouw staat op wat kost software development.

Eén ding om te beseffen. Uitstellen is bijna nooit goedkoper. Een lek dat je vindt voordat er klanten op zitten kost een dag werk. Hetzelfde lek met duizend gebruikers erop kost je een melding bij de toezichthouder, een reparatie onder tijdsdruk en een aantal klanten.

Hoe lang het duurt

Hieronder een traject van ongeveer 8 weken, van doorlichten via repareren naar live. Bij gericht onderhoud kan het in twee tot drie weken rond zijn.

Wat zeggen de cijfers?

Doorlichten en gericht verbeteren begint bij € 2.500. Substantieel herbouwen loopt van € 8.500 tot € 18.500, afhankelijk van hoeveel er behouden kan blijven. Een compleet traject duurt doorgaans 8 weken, gericht onderhoud twee tot drie. Binnen 24 uur na je aanvraag ligt er een voorstel met de aanpak en de teamsamenstelling. Onze developers zijn in vaste dienst in Varna en Dhaka, en het team in Bangladesh draait avonddiensten, waardoor je van 09:00 tot 17:30 Nederlandse tijd iemand aan de lijn hebt. Alle bedragen zijn met 0% btw.

Een lek dat je vindt voordat er klanten op zitten kost een dag. Datzelfde lek met duizend gebruikers erop kost je een melding, een reparatie onder druk en je reputatie.

Rini Petersen, founder en CEO van Devneth

Veelgestelde vragen

Wanneer is software productieklaar?

Wanneer je hem kunt openstellen voor mensen die je niet kent, op momenten dat jij niet meekijkt. Concreet betekent dat het volgende. Gegevens zijn beveiligd en per klant afgeschermd, fouten worden opgevangen en gemeld, er zijn geteste back-ups, de belangrijkste functies zijn getest en een update kan zonder stilstand live.

Kunnen jullie een project overnemen van een andere partij?

Ja, dat doen we regelmatig. We beginnen met doorlichten van de broncode, de database, de documentatie, de hosting en de beveiliging. Daarna weet je waar je staat en krijg je een plan voor afronden of opnieuw structureren. Zorg wel dat je toegang hebt tot de repository en de accounts.

Wat als de developer niet meer bereikbaar is?

Dan kunnen we vaak nog steeds verder, mits je bij de code kunt. Ontbreekt die toegang volledig, dan is herbouwen meestal de enige route. Regel toegang tot je eigen repository daarom altijd voordat je iemand inschakelt, niet erna.

Is herbouwen niet zonde van wat er al ligt?

Het voelt zo, maar reken het door. Als elke aanpassing dagen kost omdat de basis niet klopt, betaal je die keuze elke maand opnieuw. Bovendien is wat er ligt niet weg, want het ontwerp, de kennis over wat gebruikers willen en vaak delen van de code blijven bruikbaar.

Moet ik alles laten testen voordat ik live ga?

Nee, dat is voor de meeste producten overdreven. Wij testen de onderdelen waar geld of gegevens in omgaan, dus inloggen, betalen, rechten en de kernfunctie. De rest kan later, zodra je weet welke onderdelen daadwerkelijk gebruikt worden.

Wat kost het doorlichten van bestaande code?

Doorlichten en gericht verbeteren begint bij € 2.500. Je krijgt inzicht in wat goed is gebouwd, welke risico's er zijn en wat als eerste moet gebeuren. Veel klanten beginnen daarmee, omdat je dan weet hoe wij werken voordat je verder investeert.

Kan mijn software blijven draaien tijdens het verbeteren?

Meestal wel. We werken in fases en zetten wijzigingen pas live nadat ze getest zijn. Bij ingrepen in de database plannen we een moment waarop de impact het kleinst is, en er ligt altijd een back-up klaar om terug te kunnen.

Wat als mijn MVP met AI of no-code is gebouwd?

Dat komt veel voor en het is geen schande. Als demo doen die tools hun werk prima. Voor productie ontbreekt er meestal het nodige aan beveiliging, datastructuur en foutafhandeling. Wij bekijken wat er behouden kan blijven en zeggen eerlijk wanneer herbouwen goedkoper is.

Krijg ik de broncode en documentatie?

Ja. Broncode, documentatie en alle accounts staan op jouw naam en blijven van jou, ook wanneer je later met een andere partij verdergaat. Wij bouwen bewust niet zo dat alleen wij je product nog kunnen onderhouden.

Hoe snel kunnen jullie beginnen?

Binnen 24 uur na je aanvraag krijg je een voorstel met de aanpak en de teamsamenstelling. Beschikbare developers starten meestal binnen 1 tot 3 weken. Bij een acuut beveiligingsprobleem kunnen we vaak sneller schakelen, meld dat dan expliciet.

Laat je code doorlichten

Sta je nog aan het begin en moet er eerst een eerste versie komen, zie MVP laten maken. Bouw je aan een platform met meerdere klanten, lees dan software ontwikkeling. Wil je weten wat een traject kost, kijk bij wat kost software development. Zoek je capaciteit voor een specifieke rol, kijk dan bij onze developers, of neem gewoon contact op.