App ontwikkelen: dit moet je bepalen voordat je ook maar een regel code schrijft

De meeste app-projecten mislukken niet in de sprint review. Ze mislukken in de briefing. Een team bouwt maandenlang netjes wat er gevraagd wordt, om er na de lancering achter te komen dat niemand de app meer dan twee keer opent. Niet omdat de techniek niet klopt, maar omdat het product het verkeerde probleem oplost, of helemaal geen probleem oplost.

Bij Livewall zien we dit patroon keer op keer bij opdrachtgevers die eerder al een app hebben gebouwd. De app staat in de store, maar het gebruik droogt op. De fout ligt vrijwel nooit in de uitvoering. De fout ligt in de beslissingen die voor de bouw zijn genomen, of de beslissingen die helemaal niet zijn genomen.

Dit artikel legt de vragen bloot die je moet beantwoorden voordat je ook maar een designer of developer aan het werk zet.

Begin bij het gedrag, niet bij de features

Een app is geen digitale brochure. Het is een gedragsveranderingstool. Gebruikers installeren apps omdat ze iets willen doen, sneller willen doen, of makkelijker willen doen dan via een andere route.

De eerste vraag die je moet stellen is: welk specifiek gedrag wil jij aansturen? Wil je gebruikers vaker laten terugkomen? Wil je dat ze iets kopen? Wil je dat ze content consumeren, iets invullen, iets delen?

Pas als je dat gedrag concreet hebt omschreven, kun je beoordelen of een app de juiste oplossing is, en zo ja, welke mechanics je nodig hebt. Veel apps worden gebouwd omdat een concurrent ook een app heeft, of omdat iemand in de directie het een goed idee vindt. Dat zijn geen gronden voor een product.

Bij de AvroTros Eurovision Voting App was het gedrag glashelder: gebruikers moesten live kunnen stemmen, scores volgen en hun vriendengroep erbij betrekken. Die duidelijkheid maakte elke designbeslissing makkelijker. Het resultaat was de bestverkochte app in de store.

Native app, web app of progressive web app?

Dit is een van de vroegste technische keuzes, en ook een van de meest impactvolle. De meeste teams grijpen standaard naar een native iOS en Android app, maar dat is lang niet altijd de juiste keuze.

Native app: hogere ontwikkelkosten, aparte codebases voor iOS en Android, maar optimale performance en toegang tot device-functies. Zinvol als je app sterk afhankelijk is van camera, GPS, push-notificaties of offline-gebruik.

Progressive Web App (PWA): gebouwd in de browser, maar gedraagt zich als een app. Lagere kosten, sneller te lanceren, geen App Store-afhankelijkheid. Ideaal als je doelgroep breed is en performance minder kritisch.

Web applicatie: geen installatie nodig, maximale bereikbaarheid. Werkt goed als de use case primair informationeel of transactioneel is en geen apparaatfuncties vereist.

Bij Livewall maken we deze keuze samen met de opdrachtgever op basis van de daadwerkelijke use cases, niet op basis van aannames. Zie ook onze aanpak voor iOS en Android ontwikkeling.

Valideer de kern, niet de volledige roadmap

Een veelgemaakte fout is het proberen te bouwen van de complete, definitieve versie in de eerste release. Het resultaat is een app die negen maanden duurt om te bouwen, en bij lancering al niet meer aansluit bij de markt.

De betere aanpak: definieer de kernhypothese. Wat is de ene centrale reden waarom iemand deze app zou gebruiken? Bouw dat eerste, test het met echte gebruikers, en pas daarna bouw je verder.

Onze MVP ontwikkeling aanpak is precies hierop gericht: de kleinst bruikbare versie die je kernhypothese valideert, in weken in plaats van maanden. Dat is geen compromis op kwaliteit. Het is de slimste manier om risico te beheersen.

Voor Sportvisunie begonnen we met een scherp afgebakend communityplatform, gebouwd rondom de centrale gedraging: hengelsportkennis uitwisselen. Door gefocust te bouwen, konden we snel leren en het platform daarna doelgericht uitbreiden.

Welke data heb je, en welke data wil je?

Een app is ook een datapunt. Elke interactie kan je iets vertellen over gebruikersgedrag. Maar te weinig teams denken hierover na voor de bouw begint.

Bepaalde vragen die je voor lancering moet beantwoorden:

• Welke gebruikersacties wil je meten?
• Hoe integreert de app met je CRM of loyaliteitsplatform?
• Welke first-party data kun je verantwoord verzamelen via de app?
• Hoe gebruik je die data om de app en je communicatie te verbeteren?

Data-architectuur is geen bijzaak. Als je er niet over nadenkt voor de bouw, bouw je een systeem dat later onmogelijk te koppelen is aan je andere platformen.

Hoe ziet terugkerend gebruik eruit?

Een app die mensen één keer gebruiken en daarna verwijderen is weggegooid geld. De echte waarde van een app zit in terugkerend gebruik. De vraag is: wat is de reden waarom iemand de app morgen opent, en overmorgen?

Dit moet je antwoorden hebben voor je begint:

• Wat is de dagelijkse of wekelijkse use case?
• Hoe informeer je gebruikers over nieuwe content of functionaliteit?
• Welke game mechanics, beloningen of triggers stimuleren herbezoek?

Bij de KLM Scalable Growth Case zat de herkomst van terugkerend gebruik ingebouwd in de productstrategie, niet achteraf toegevoegd.

De bouwkeuze: intern of extern team?

Veel merken worstelen met de keuze tussen een eigen intern team, een extern bureau of een hybride model. Er is geen universeel antwoord, maar er zijn duidelijke signalen.

Een extern team zoals Livewall is zinvol als:

• Je geen product-engineering capaciteit in huis hebt
• Je snel wilt valideren zonder een heel team op te bouwen
• Je strategie, UX-design en ontwikkeling in één team wilt
• Je een senior product perspective nodig hebt bij productkeuzes

Een intern team is zinvol als:

• De app een lang-cyclus product is met doorlopende iteratie
• Je de IP volledig intern wilt houden
• Je al sterke product ownership hebt

In de praktijk zien we het meeste succes bij een samenwerking: Livewall als lead voor strategie, design en de initiële bouw, met een overdracht naar een intern team voor beheer en doorontwikkeling.

Zorg dat iemand eigenaar is

Elk succesvol app-project heeft een interne product owner. Niet een projectmanager die vergaderingen plant, maar iemand die beslissingen neemt, prioriteiten stelt en verantwoordelijk is voor het resultaat.

Zonder die eigenaar worden beslissingen uitgesteld, compromissen gemaakt die niemand wil, en raakt het project stuurloos. Dit is geen procesadvies. Het is de meest voorkomende oorzaak van mislukte app-projecten die wij zien.