Hoe lang duurt het om een app te ontwikkelen? Ons traject in 4–8 weken

Een eerste versie van een app staat bij ons meestal binnen 4 tot 8 weken live. Dat is geen kwestie van harder werken, maar van scherp kiezen: wat moet er in versie 1, en wat kan wachten tot je weet hoe gebruikers reageren? In dit artikel lees je wat bepaalt hoe lang app-ontwikkeling duurt, hoe zo'n traject van week tot week verloopt, hoe we vooraf een vaste prijs afspreken en wat er in versie 1 zat bij een aantal projecten die we bouwden.

De korte versie

• MVP of eerste versie: 4 tot 8 weken, afhankelijk van hoeveel er in moet.
• De grootste factor is de scope, niet het aantal schermen: gebruikersrollen, betalingen, koppelingen en realtime functies kosten de meeste tijd.
• Prijs en deadline liggen vooraf vast. Na een gratis intake krijg je één vaste prijs en een opleverdatum, die niet veranderen zolang de scope gelijk blijft.
• Je ziet elke week een werkende versie, zodat je onderweg kunt bijsturen in plaats van pas aan het eind.

Wat bepaalt hoe lang het duurt?

Twee apps met evenveel schermen kunnen een paar weken verschillen in doorlooptijd. Dit zijn de factoren die het meeste uitmaken:

• Gebruikersrollen. Een app voor één type gebruiker is sneller klaar dan een platform waarop klanten, aanbieders en beheerders elk iets anders zien.
• Betalingen. Afrekenen, abonnementen of uitbetalingen aan derden vragen extra bouw- en testwerk.
• Koppelingen. Elke koppeling met een ander systeem, zoals een kassasysteem, boekhouding of externe API, hangt ook af van hoe goed dat systeem gedocumenteerd is.
• Realtime en hardware. Live statussen, meldingen die direct moeten aankomen of een koppeling met een scanner of touchscreen.
• Wachttijd. Feedback, teksten, logo's en toegang tot accounts die op zich laten wachten, schuiven de planning net zo hard op als technische problemen.
• Publicatie. Apple en Google beoordelen een app voordat hij in de stores komt. Meestal duurt dat een paar dagen, maar plan er wat ruimte voor.

Zo verloopt een traject van 4 tot 8 weken

1. Ontdekking. In de gratis intake bespreken we je doel, je gebruikers en wat de app minimaal moet kunnen. We vragen vooral door op wat er níet in versie 1 hoeft.
2. Scope en planning. We leggen vast welke schermen, rollen en koppelingen er komen. Je krijgt één vaste prijs en een opleverdatum voordat er een regel code geschreven is.
3. Bouwen en bijsturen. Het grootste deel van het traject. Je krijgt elke week een werkende versie om op je eigen telefoon te proberen en geeft direct feedback.
4. Testen en lanceren. We testen met echte gebruikers, publiceren in de App Store en Google Play en richten hosting en monitoring in. Na de lancering blijven we beschikbaar voor verbeteringen.

Meer over elke stap lees je op de pagina over ons proces.

En een webapplicatie?

Voor een webapplicatie, zoals een klantportaal, een intern dashboard of een SaaS-MVP, geldt dezelfde termijn van 4 tot 8 weken. Een paar dingen zijn wel anders:

• Geen beoordeling door een app store. Een webapplicatie staat live zodra hij klaar is, en een update ook. Dat scheelt aan het eind een paar dagen en maakt bijsturen na de lancering sneller.
• Koppelingen en de beheeromgeving bepalen de planning. Bij webapplicaties zit het meeste werk vaak niet in de schermen, maar in de aansluiting op systemen die je al gebruikt, zoals je CRM of boekhouding, en in wat beheerders moeten kunnen.
• Eén versie voor elk apparaat. Een goede webapplicatie werkt op laptop, tablet en telefoon, zonder aparte iOS- en Android-versie.

Twijfel je of je een webapplicatie of een app nodig hebt? Begin dan bij de vraag of gebruikers echt functies van de telefoon nodig hebben, zoals meldingen op de achtergrond of de camera. In Web-app of native app? zetten we de opties naast elkaar. Meer over webapplicaties lees je op de pagina webapplicaties laten maken.

Transparante prijzen: zo leggen we de prijs vooraf vast

We werken niet met uurtje-factuurtje voor een eerste versie. Na de intake krijg je één vaste prijs die past bij de scope. Als indicatie, op basis van onze eigen projecten:

Wil je halverwege iets toevoegen? Dan kijken we samen wat ervoor kan wijken, of zetten we het op de lijst voor versie 2. Zo blijven prijs en deadline staan. Hoe die bedragen zijn opgebouwd, lees je in Wat kost een app laten ontwikkelen?.

Wat er in versie 1 zat: voorbeelden uit onze projecten

Elke eerste versie is anders, omdat elk product een ander kernprobleem oplost. Een paar voorbeelden van wat we in versie 1 bouwden, en waarom.

Glasfixer: klein beginnen met drie producten

Glasfixer maakt glas op maat, waardoor elke bestelling vroeger een offerte en handwerk was. In plaats van meteen het hele assortiment online te zetten, startte de webshop met prijscalculator met drie producten. Klanten vullen afmetingen en glasdikte in en zien direct de prijs. Resultaat: Glasfixer hoeft orders niet meer handmatig in te boeken en bespaart 10 uur per week. Meer producten toevoegen kan nu op een bewezen basis.

Spichaser: investeren waar het risico zit

De kern van Spichaser is een tijdige waarschuwing als je mogelijk gevolgd wordt. Daar zat ook de grootste uitdaging, en dus de meeste aandacht: een eigen server die grote hoeveelheden kentekendata verwerkt en meldingen op tijd verstuurt. De app zelf bouwden we in React Native, zodat één codebase op iOS en Android draait. Zo ging de tijd naar het deel dat het product maakt of breekt.

Akhie: vertrouwen hoort bij de kern

Bij een platform waar gasten bij thuiskoks eten, is vertrouwen geen extraatje. Daarom zaten verificatie, beoordelingen en veilige betalingen tussen gasten en gastheren al in de eerste versie van Akhie, net als ondersteuning voor meerdere talen. Wat in versie 1 hoort, hangt dus af van het product: soms is dat meer dan je zou denken.

Haagse Taxi: één keer bouwen, twee keer gebruiken

De eigenaar van Haagse Taxi heeft ook de Haagse Taxi Centrale. In plaats van twee boekingssystemen bouwden we één boekingsplatform waarop beide merken draaien, elk met een eigen website en uitstraling. Klanten zien vooraf een vaste ritprijs. Tarieven en boekingen staan op één plek, dus het tweede merk hoefde niet opnieuw gebouwd te worden.

Tapp: een platform in losse onderdelen

Tapp laat festivalbezoekers drankjes bestellen via een app en ophalen bij containers. Rond de bestelapp bouwden we ook een kassatablet voor barpersoneel en een touchscreen-interface voor de containers. Elk onderdeel is een afgebakend project dat met dezelfde backend praat. Zo groeit een groot platform in stappen die elk een eigen planning en prijs hebben.

De rode draad: een snelle lancering komt niet van minder zorg, maar van een kleinere eerste versie. Kies het ene probleem dat je product moet oplossen, bouw dat goed, en laat de rest wachten tot gebruikers vertellen wat ze nodig hebben.

Waarom het soms toch langer duurt

Ook met een vaste planning kan het uitlopen. De meest voorkomende oorzaken:

• De scope groeit onderweg. Elke "kleine toevoeging" kost tijd. Daarom ruilen we liever dan dat we stapelen.
• Een externe partij is traag. Een API zonder documentatie, of een leverancier die lang doet over toegang.
• Feedback blijft uit. Als een werkende versie een week ongezien blijft, schuift de rest mee.
• De store keurt de app af. Apple heeft strenge richtlijnen; een afwijzing betekent aanpassen en opnieuw indienen.

Zo houd je zelf het tempo erin

• Wijs één persoon aan die beslissingen neemt en elke week de nieuwe versie bekijkt.
• Zorg vroeg voor teksten, logo's en toegang tot accounts en systemen.
• Maak alvast een Apple- en Google-ontwikkelaarsaccount aan op naam van je bedrijf; dat kan een paar dagen duren.
• Schrijf ideeën die opkomen tijdens de bouw op voor versie 2, in plaats van ze er nog in te proppen.

Wil je weten hoe lang jouw app duurt?

In een gratis intake kijken we wat de kleinste versie van jouw idee is en krijg je een vaste prijs en opleverdatum. Lees vooraf ook Wat is een MVP? en hoe je de juiste partij kiest, of bekijk al onze cases.