Een app uit een weekend werkt vaak goed als demo, maar mist wat nodig is voor echte gebruikers. Denk aan inloggen en rechten, een database met back-ups, beveiliging, hosting en iemand die het oplost als het misgaat.
Je beschreef in gewone taal wat je wilde, in Lovable, Bolt of Cursor, en zondagavond stond het er. Schermen, knoppen, een flow die klopt. Je liet het zien en mensen snapten meteen wat je bedoelde. Maandag wil je de eerste klant laten inloggen. En dan blijkt dat werken iets anders is dan live kunnen.
Wat het prototype goed doet
Eerst dit: wat je hebt gebouwd, is echte winst.
Je hebt laten zien wat je wilt, in plaats van het te beschrijven. Dat is vaak het lastigste deel van een softwareproject: uitzoeken wat er eigenlijk gebouwd moet worden. Een lijst met wensen kun je op tien manieren lezen. Een werkend scherm maar op één.
Je hebt je idee getest voordat je er veel geld in stak. Je weet welke schermen mensen snappen en waar ze vastlopen. En een ontwikkelaar die verder bouwt, ziet meteen wat je bedoelt.
Gooi dat dus niet weg. Maar zet het ook nog niet live.
Wat het nog mist
Een prototype bouwt wat je vraagt. Je vroeg om schermen voor een goede dag. Wat er gebeurt op een slechte dag, vroeg je niet, en dat zit er dus ook niet in.
- Inloggen en rechten. Vaak is er één wachtwoord voor iedereen, of helemaal geen inlog. Wie welke gegevens mag zien, staat hooguit in het scherm geregeld. Wie een beetje handig is met de browser, komt er toch bij. Rechten horen op de server.
- Een echte database en back-ups. De gegevens staan in de browser, in het geheugen of op een gratis plan met grenzen. Een back-up is er niet, of hij is nooit teruggezet. Een back-up die je nooit hebt teruggezet, is een hoop, geen back-up.
- Beveiliging. De sleutel van een betaalde dienst staat in de code die elke browser binnenhaalt. Wie hem vindt, gebruikt hem op jouw rekening. Formulieren hebben geen grens, dus een script kan ze eindeloos invullen.
- Hosting. De app draait op een preview-link van de tool, of op een gratis plan met een plafond. Een eigen domein, een certificaat en een server in Europa voor de gegevens van je klanten zijn er nog niet.
- Fouten en logging. Gaat er iets mis bij een gebruiker, dan staat de fout in diens browser. Jij ziet niets. Je hoort het pas als een klant belt, of juist niet belt en wegblijft.
- Onderhoud en updates. Je app staat op pakketten van anderen, en die krijgen beveiligingsupdates. Over een jaar is er niets bijgewerkt, en de volgende wijziging breekt iets wat er los van leek te staan.
- Wie het oplost om 7 uur 's ochtends. De app ligt plat en je eerste klant kan niet inloggen. Wie krijgt de melding? Wie kan de code lezen? Wie zet de vorige versie terug? Is het antwoord drie keer "ik, denk ik", dan weet je wat er ontbreekt.
Zit er AI in je app zelf, zoals een chat die vragen over je gegevens beantwoordt? Dan komt er een punt bij. Het model mag niet meer zien dan de gebruiker die de vraag stelt, en elke vraag hoort in een logboek. Hoe we dat in een bestaande Laravel-app bouwen, staat bij AI in je software.
Afmaken in plaats van opnieuw beginnen
Leg je prototype voor aan een ontwikkelaar en soms hoor je: dit gooien we weg, we beginnen opnieuw.
Soms is dat terecht, maar het is geen wet. De schermen en de flow zijn precies wat je met echte mensen hebt getest. Die hoeven niet opnieuw. Wat ontbreekt, zit eronder: de inlog, de database, de server, de meldingen. Dat bouw je eronder zonder dat je gebruikers er iets van merken, behalve dat het blijft werken.
Welke tool je ook gebruikte, het resultaat is gewoon code. Iemand die het vak kent, leest die code en gaat verder waar jij gebleven bent. Per onderdeel kijk je wat blijft, wat wordt aangepast en wat opnieuw moet. Meestal is het een mix.
Opnieuw bouwen is pas logisch als het meeste plakwerk is uit losse sessies, en niemand de logica nog kan volgen. Ook dan is je prototype niet verloren. Het is de beste beschrijving van wat je wilt die je kunt hebben.
Wil je zelf blijven doorbouwen met AI? Dat kan. Doe het dan op een testomgeving, met tests en een review voordat iets live gaat. Dan houd je het tempo, en breekt het niet bij je klanten.
Checklist: loop je eigen app langs
Zeven vragen. Beantwoord ze eerlijk met ja of nee.
- Rechten. Ziet elke gebruiker alleen wat bij zijn rol hoort, en controleert de server dat, niet alleen het scherm?
- Data. Staan je gegevens in een echte database, en heb je ooit een back-up teruggezet?
- Sleutels. Staan er geen API-sleutels of wachtwoorden in de code die de browser binnenhaalt?
- Hosting. Draait de app op je eigen domein en op hosting op jouw naam, met klantgegevens in Europa?
- Fouten. Krijg jij een melding als er bij een gebruiker iets misgaat, voordat die gebruiker jou belt?
- Updates. Weet je wie de updates doet, en wanneer dat voor het laatst gebeurde?
- Storing. Weet je wie je belt als de app om 7 uur 's ochtends plat ligt? En kan die de code lezen en een versie terugzetten?
Zeven keer ja, dan staat het fundament. Elk nee is een klus die eerst moet. Begin bij de vragen die over de gegevens van je klanten gaan: rechten, data en sleutels.
Zo maak je het af
Bij vibe-code naar product lees je hoe wij een prototype lezen, productieklaar maken en live zetten op je eigen domein. Je werk blijft staan; wat wij toevoegen, zit eronder.
Welke software past bij jou? 5 vragen. Doe de bouwcheck. Geen account, geen e-mail.
Weet je al wat je wilt? Plan een intake. Je praat direct met wie het bouwt.
