Ga naar hoofdinhoud

Webapps

Waarom de eerste versie van je webapp maar één ding moet doen

·2 min lezen

Bij een nieuwe webapp komt een klant vaak met een lijst. Inloggen, rollen, rapportages, facturen, een dashboard, notificaties, een mobiele weergave.

Allemaal nuttig. En precies de reden dat veel apps blijven steken voordat ze ooit gebruikt worden.

Wat een lange lijst kost

Hoe meer een eerste versie moet, hoe later hij af is en hoe meer er kan breken. Elke functie wil getest, elke functie hangt aan een andere, en elke week uitstel is een week waarin niemand de app gebruikt.

Het pijnlijke is dat je in die maanden bouwen niet leert of het ding klopt. Je gokt. En een app die op een gok van een half jaar geleden gebouwd is, raakt bijna altijd net naast wat de gebruiker echt nodig had.

De ene vraag die ik stel

Voor ik begin, vraag ik: "Wat is het ene dat deze app moet kunnen, waarzonder hij geen punt heeft?"

Niet drie dingen. Eén.

Bij een offerte-tool is dat: een offerte invoeren en er een net document uit krijgen. Niet de klantenadministratie, niet de omzetgrafiek, niet de koppeling met de boekhouding. Eén handeling, van begin tot eind, die werkt.

Die ene handeling bouw ik eerst. En zodra die werkt, gaat hij live, ook al kan de app verder bijna niks.

Waarom kaal beginnen sneller is

Een app die één ding goed doet, kun je binnen weken in gebruik nemen in plaats van maanden. En vanaf dat moment leer je dingen die geen enkele planning je geeft.

Je ziet waar de gebruiker vastloopt. Je hoort welke functie als eerste echt gemist wordt, en die blijkt zelden bovenaan de oorspronkelijke lijst te staan. Je bouwt de tweede functie op wat je weet, niet op wat je gokte.

Zo groeit de app in de richting die het gebruik aanwijst. Dat is goedkoper en bijna altijd beter dan alles vooraf bedenken.

Wat er met de rest van de lijst gebeurt

De lijst verdwijnt niet. Hij wordt een volgorde.

Rollen, rapportages, dat dashboard: ze komen, maar pas als de basis draait en als blijkt dat ze echt nodig zijn. Soms valt de helft van de oorspronkelijke lijst weg omdat hij in de praktijk niet bleek te kloppen. Dat is geen verlies. Dat is werk dat je niet voor niks deed.

Het advies in één zin

Bouw niet de app die alles kan. Bouw het ene dat zonder de app niet kan, zet dat live, en laat de rest volgen op wat je daarna ziet.

Een kale eerste versie die draait is meer waard dan een complete versie die nog niet bestaat.


Zie ook: Begin met het lelijkste scherm en Wanneer een spreadsheet nog steeds beter is dan een app. Een webapp-idee scherp krijgen? Bekijk hoe ik webapps bouw of plan een gesprek.