In het kort
- De duur van een app project hangt vooral af van hoe duidelijk je weet wat de app moet doen, en van hoeveel er in de eerste versie zit.
- Een app gaat door vaste fases: idee scherpstellen, ontwerp, bouw, testen en lancering. Elke fase overslaan kost later meer tijd.
- Wie klein start met een eerste versie die het kernprobleem oplost, staat het snelst met iets werkends bij de gebruikers.
Waarom er geen standaardantwoord is
Hoe lang duurt het om een app te laten maken? Het eerlijke antwoord is: dat hangt ervan af. Niet als uitvlucht, maar omdat twee apps die op het eerste zicht gelijk lijken, totaal anders kunnen zijn.
Een app waarmee medewerkers hun uren registreren, is iets anders dan een app waarin klanten online betalen, afspraken boeken en berichten sturen, gekoppeld aan je boekhouding en planning. Allebei een app, maar het verschil in werk is groot.
Wat de duur vooral bepaalt, is niet het programmeren zelf. Het is hoe duidelijk je weet wat de app moet doen, hoeveel functies er in de eerste versie zitten en met hoeveel andere systemen ze moet praten. Daar draait dit artikel om.
De fases van een app project
Elk serieus app project doorloopt dezelfde fases. Ze kunnen kort of lang zijn, maar overslaan is geen goed idee. Wat je vooraf niet uitzoekt, moet je later herbouwen.
- Idee scherpstellenWelk probleem lost de app op, voor wie, en wat is de kleinste versie die al waarde heeft?
- Functioneel ontwerpWelke schermen zijn er, wat kan een gebruiker doen, en welke gegevens worden bewaard of gekoppeld?
- Visueel ontwerp en prototypeEen klikbaar voorbeeld waarmee je de app kan doorlopen voor er één regel code geschreven is.
- BouwenOntwikkeling in korte rondes, zodat je tussentijds kan zien en bijsturen wat er gebouwd wordt.
- TestenOp verschillende toestellen, met echte gebruikers en echte gegevens. Hier komen de verrassingen boven.
- LanceringOnline zetten, of publiceren in de App Store en Google Play, inclusief de controle door Apple en Google.
Wat de app moet kunnen, bepaalt de duur
Om in te schatten waar jouw project zit, helpt het om apps in drie soorten op te delen. Het gaat niet om het aantal schermen, maar om wat er achter de schermen moet gebeuren.
Een eenvoudige app toont informatie en laat gebruikers een paar dingen invullen. Een gemiddelde app heeft gebruikersaccounts, verschillende rollen, een eigen database en een beheeromgeving. Een complexe app koppelt met meerdere externe systemen, verwerkt betalingen, werkt offline of verwerkt gevoelige gegevens met strenge beveiligingseisen.
Elke stap omhoog voegt niet een beetje werk toe, maar een nieuwe laag: meer schermen, meer testen, meer uitzonderingen en meer afspraken met andere partijen.
- Eenvoudig: informatie tonen en formulieren invullen
- Gemiddeld: accounts, rollen, eigen database en beheer
- Complex: koppelingen, betalingen, offline werken, gevoelige gegevens
Wat een project sneller maakt
Sommige projecten lopen vlot, andere slepen maanden aan. Het verschil zit zelden bij de ontwikkelaars, en vaak in de voorbereiding.
Een project gaat sneller als er één persoon aan jouw kant beslissingen kan nemen. Als je weet wie de gebruikers zijn en hoe ze vandaag werken. Als teksten, logo's, prijzen en voorbeeldgegevens klaarliggen. En als je bereid bent om met een eerste versie te starten in plaats van alles meteen te willen.
- Eén beslisser met tijd om feedback te geven
- Een duidelijk beeld van de gebruikers en hun werk
- Inhoud en gegevens die klaarliggen
- Een kleine eerste versie in plaats van alles tegelijk
- Bestaande software met een goede API om aan te koppelen
Wat een project vertraagt
De grootste vertragers zijn herkenbaar. Bovenaan staat de lijst met wensen die tijdens het bouwen blijft groeien. Elke extra functie lijkt klein, maar samen schuiven ze de lancering steeds verder op.
Daarnaast zijn er de koppelingen. Een app die met je boekhouding, je planning of een extern platform moet praten, hangt af van hoe goed die systemen openstaan. Een slecht gedocumenteerde of trage API kan veel tijd kosten.
En er is wachttijd. Feedback die dagen op zich laat wachten, beslissingen die telkens worden uitgesteld, of een goedkeuring in de App Store die opnieuw moet omdat er iets ontbrak. Dat zijn weken die niemand plande.
Begin met een eerste versie die werkt
De snelste manier om een app in handen van gebruikers te krijgen, is klein beginnen. In de softwarewereld heet dat een minimum viable product: de kleinste versie die het kernprobleem oplost.
Stel dat je een app wil voor je techniekers. De eerste versie toont de planning van de dag, laat hen uren en materiaal invullen en de klant laten tekenen. Rapporten, statistieken en een klantenportaal komen later.
Zo zie je snel of de app echt gebruikt wordt, en wat er ontbreekt. Je bouwt verder op basis van wat je techniekers vragen, niet op basis van wat je vooraf dacht dat ze nodig hadden.
Webapp of app in de store?
Niet elke app moet in de App Store of Google Play staan. Een webapplicatie werkt in de browser, op elke computer, tablet en smartphone. Je kan ze ook op het beginscherm zetten, zodat ze aanvoelt als een gewone app.
Een webapp is vaak sneller klaar. Je bouwt één versie in plaats van twee, er is geen goedkeuring door Apple of Google nodig en updates zijn meteen voor iedereen beschikbaar.
Een app in de store is zinvol als je veel gebruik maakt van functies van het toestel, zoals de camera, meldingen of offline werken, of als je klanten verwachten dat ze je app in de store vinden. Voor een publicatie in de stores rekent Apple een jaarlijkse bijdrage voor het ontwikkelaarsaccount en Google een eenmalige registratie.
- Webapp: één versie, geen goedkeuring nodig, updates meteen live
- Store app: beter voor intensief gebruik van camera, meldingen en offline
- Combinatie: een webapp voor kantoor en een app voor op de baan
Na de lancering is het niet gedaan
Een app is geen folder die je één keer drukt. Na de lancering komen er vragen, kleine fouten en nieuwe wensen. Besturingssystemen krijgen updates, en ook Apple en Google passen hun regels regelmatig aan.
Plan daarom vanaf het begin onderhoud in. Wie volgt de app op, wie beantwoordt vragen van gebruikers en hoe vaak komen er verbeteringen bij? Een app die niet onderhouden wordt, werkt na een tijd minder goed of verdwijnt zelfs uit de store.
Zie de lancering dus als het begin van een tweede fase: luisteren naar gebruikers en de app stap voor stap beter maken.
Zo krijg je een realistische planning
Een goede ontwikkelaar geeft je geen termijn op basis van een gesprek van tien minuten. Die stelt vragen, maakt een eerste ontwerp en geeft dan een planning per fase.
Vraag die planning ook op. Wanneer zie je een eerste prototype? Wanneer kan je zelf testen? Wanneer gaat de eerste versie live? Zo zie je onderweg of het project op schema zit, in plaats van pas aan het einde.
En wees eerlijk over je eigen beschikbaarheid. Als jij twee weken op vakantie bent tijdens de testfase, schuift alles mee. Een planning is altijd een afspraak tussen twee partijen.
- Vraag een planning per fase, niet één einddatum
- Spreek vaste momenten af om tussentijds te kijken
- Leg vast wat in de eerste versie zit en wat later komt
- Plan je eigen tijd voor feedback en testen mee in