App laten maken: zo verloopt het traject van gesprek tot livegang

Wat je klaarlegt vóór het eerste gesprek

Een goed eerste gesprek duurt twintig minuten en levert een plan op. Een slecht eerste gesprek duurt anderhalf uur en levert een tweede gesprek op. Het verschil zit bijna volledig in de voorbereiding. Vijf dingen zijn genoeg:

1. 1Het probleem in één zin. Niet "we willen een app", maar "onze monteurs vullen werkbonnen 's avonds thuis in op papier en wij typen ze de dag erna over". Wie het probleem kan opschrijven, krijgt een scherpere prijs.
2. 2Wie hem gaat gebruiken, en met hoeveel. Tien monteurs is iets anders dan tweeduizend consumenten — voor het ontwerp, voor de hosting en voor de vraag of je überhaupt in de app-stores moet staan.
3. 3Een lijst van must-haves en nice-to-haves. Schrijf alles op wat in je hoofd zit en zet er daarna een streep doorheen: alles onder die streep is versie twee. Dit is de enige oefening die je later duizenden euro's scheelt.
4. 4De systemen waar hij mee moet praten. Boekhouding, webshop, CRM, planning. Noteer de naam van het pakket, niet alleen de categorie — "Exact Online" is bruikbaar, "onze boekhouding" niet.
5. 5Een budgetkader en een datum. Geen exact bedrag, wel een orde van grootte en de reden achter je deadline (een beurs, een seizoen, een contract dat afloopt). Een bouwer kan scope schuiven, geen tijd verzinnen.

Weet je nog niet zeker of je idee klaar is voor deze stap, lees dan eerst hoe je van een app-idee naar een werkende app gaat. Daar staan de vijf vragen waarmee je toetst of het idee hout snijdt.

Fase 1: het gesprek en het plan met vaste prijs

In het eerste gesprek hoort de bouwer vooral te luisteren en door te vragen: wat gebeurt er nu, wie raakt het aan, wat mag er weg. Wat je daarna terugkrijgt is geen dikke offerte van twintig pagina's, maar een plan dat je in vijf minuten kunt lezen. Bij VibeCodex ligt dat er binnen een dag.

In een bruikbaar plan staat in elk geval:

• Wat er gebouwd wordt — de schermen en functies van versie één, benoemd, zodat je ze kunt aftellen.
• Wat er bewust níet in zit en waarom het kan wachten. Dit is het belangrijkste lijstje van het hele document.
• Een vaste totaalprijs, inclusief testen, bugfixes en livegang — geen uurtarief met een schatting erachter.
• Een tijdlijn met momenten waarop jij meekijkt, niet alleen een opleverdatum.
• De lopende kosten na livegang, uitgesplitst per maand en per jaar.

”De waarde van een plan zit niet in de lijst met functies, maar in de lijst met functies die er bewust niet in zitten.

De tijdlijn: wat er in twee tot drie weken gebeurt

Onderstaande tijdlijn is die van een zakelijke app of portaal met inlog, opslag en één of twee koppelingen — verreweg de meest voorkomende opdracht in het mkb. Consumentenapps die in de App Store en Play Store moeten staan, tellen er de publicatieprocedure bij op.

Dat dit in weken kan in plaats van maanden, komt doordat het handwerk korter is geworden, niet doordat er stappen zijn overgeslagen. Ontwerp, bouw, test en livegang zitten er allemaal in; de AI schrijft de code, de developer stuurt bij en bewaakt de kwaliteit. Hoe dat werkt zonder dat je inlevert op kwaliteit, staat in het artikel over professioneel bouwen met AI.

Fase 2: bouwen, met elke week iets om aan te klikken

De klassieke valkuil is de black box: je tekent, en drie maanden later staat er een demo. Wat er in die maanden aan misverstanden is ingebouwd, blijkt dan pas — en herstellen kost dan het meeste geld. De remedie is simpel en zou standaard moeten zijn: je krijgt elke week een link naar de werkende versie, niet naar een presentatie.

Dat vraagt ook iets van jou. Vijf minuten per week doorklikken en drie zinnen terugsturen is genoeg, maar het moet wél gebeuren. De feedback die in week één komt is bijna gratis te verwerken; dezelfde opmerking in week drie betekent opnieuw bouwen. Reken erop dat je in het hele traject twee tot vier uur van je eigen tijd kwijt bent — minder is een risico, meer is meestal niet nodig.

Koppelingen: de fase waarin de meeste vertraging zit

Als een app-traject uitloopt, gebeurt dat zelden in het bouwwerk en bijna altijd bij de koppelingen. Niet omdat het technisch ingewikkeld is, maar omdat er wachttijd in zit die niemand vooraf inplant: API-sleutels die bij een externe leverancier opgevraagd moeten worden, een testomgeving die je niet zelf kunt aanmaken, of een pakket waar iemand anders in jouw organisatie de beheerder van is.

Regel daarom in week één wie welke toegang heeft, en vraag ontbrekende sleutels meteen aan. Dat kost je een mailtje en bespaart later een week. Welke systemen zich makkelijk laten koppelen en welke niet, staat in het artikel over systemen koppelen.

Fase 3: de livegang, en wat daar precies bij hoort

Live gaan is meer dan een knop omzetten. Op die dag hoort dit geregeld te zijn:

• Domein en beveiligde verbinding (HTTPS), met de app op jouw eigen domein of subdomein.
• Accounts en rechten: wie mag wat, en wie is beheerder als jij er niet bent.
• Back-ups en monitoring: een dagelijkse back-up en een melding als er iets stukgaat, zodat jij het niet van een klant hoeft te horen.
• Analytics: zodat je na twee weken ziet wat mensen echt doen in plaats van wat je hoopte.
• Toegang tot de broncode: de repository staat op jouw naam, niet op die van de bouwer.
• Publicatie in de stores, als je een app hebt die daar hoort te staan — inclusief certificaten, privacygegevens en de beoordelingsprocedure van Apple en Google. Reken op een paar dagen speling: een afwijzing op een formaliteit is normaal en meestal binnen een dag hersteld.

Kies je voor een web-app, dan vervalt die laatste post volledig. Voor de meeste zakelijke toepassingen is dat de nuchtere keuze: één codebase, geen beoordelingsprocedure, en elke update staat direct bij al je gebruikers. De volledige afweging tussen web-app, cross-platform en native staat in wat kost een app laten maken.

De eerste 90 dagen na de lancering

De livegang is niet het einde van het traject maar het begin van het bruikbare deel. Wat er in de eerste drie maanden gebeurt, bepaalt of de app blijft leven:

1. 1Week 1–2: kleine oneffenheden die alleen bij echt gebruik boven komen. Reken erop, plan er ruimte voor, en spreek af wat daarvan onder garantie valt.
2. 2Week 3–6: de eerste inhoudelijke wensen. Nu is het moment om de lijst uit je voorbereiding erbij te pakken en te kijken wat er van versie twee écht nog nodig blijkt.
3. 3Week 7–12: de cijfers. Wordt de app dagelijks gebruikt door de mensen voor wie hij bedoeld is? Zo niet, dan is dat een gesprek over gebruik en gewoontes, geen bouwopdracht.

Lopende kosten zijn in deze periode voorspelbaar: hosting en database (maandelijks, naar gebruik), eventueel de developer-accounts als je in de stores staat, en onderhoud — updates van onderliggende software, back-ups, monitoring en kleine verbeteringen. Laat dat vooraf uitgesplitst op papier zetten, dan zijn er geen verrassingen.

Vijf afspraken die op papier horen voordat je tekent

Of je nu met VibeCodex werkt of met een ander: dit zijn de vijf punten waarop je offertes vergelijkt, en ze zeggen meer over de samenwerking dan het eindbedrag.

1. 1Vaste totaalprijs, inclusief testen, bugfixes en livegang. Een uurtarief met een schatting is geen prijs, maar een intentie.
2. 2De scope van versie één, benoemd per scherm of functie, plus wat er bewust buiten valt.
3. 3Code-eigenaarschap: de broncode en repository zijn van jou, zodat je nooit vastzit aan één partij.
4. 4Lopende kosten per maand en per jaar, uitgesplitst — hosting, database, accounts, onderhoud.
5. 5Eén aanspreekpunt en een afgesproken reactietijd, ook ná de livegang.

Vier dingen die een app-traject laten ontsporen

• Alles in versie één willen. De duurste app is niet die met de hoogste offerte, maar die vol functies die niemand gebruikt.
• Niet meekijken tijdens het bouwen. Feedback in week één is bijna gratis; dezelfde opmerking in week drie is opnieuw bouwen.
• Koppelingen te laat regelen. Sleutels en toegang zijn geen technisch probleem maar een wachttijdprobleem — start ze in week één.
• Geen afspraak over daarna. Een app zonder onderhoudsafspraak is over een jaar een app die niemand meer durft aan te raken.

Wil je zien hoe dit er bij echte opdrachten uitpakte, bekijk dan het portfolio — bijvoorbeeld de iOS-app Battery Pilot of het dealerportaal voor Protektis. En overweeg je eigenlijk eerder een omgeving waar je klanten inloggen dan een app in de stores, lees dan klantportaal laten maken.

Kort samengevat

Een app laten maken is geen sprong in het diepe als het traject transparant is: je legt vooraf één probleem en een korte lijst must-haves neer, je krijgt binnen een dag een plan met vaste prijs, je kijkt elke week mee in een werkende versie, en je gaat pas live als jij akkoord geeft. Hoe dat er stap voor stap uitziet, staat op de pagina app laten maken en in de werkwijze van VibeCodex: van gesprek tot live, meestal binnen één tot drie weken.