Bijna elke aanvraag voor een app begint met dezelfde zin: we willen een app. En bijna nooit is een app het eerste juiste antwoord. Er loopt een proces vast, en de vraag is welke vorm dat proces het snelst uit de knoop haalt.
Eerst de vraag achter de vraag
Voordat je over techniek praat, wil je weten welk gedrag je probeert te veranderen. In de praktijk komen aanvragen bijna altijd terug op een van deze drie: klanten bellen om te vragen hoe het met hun order of aanvraag staat, het team houdt de waarheid bij in een gedeelde spreadsheet, of iemand kopieert elke ochtend gegevens van het ene systeem naar het andere.
Dat zijn drie verschillende problemen met drie verschillende oplossingen. Statusvragen los je vaak op met een simpele pagina achter een link. Een spreadsheet die de waarheid is, vraagt om een echte applicatie. Handmatig overtypen vraagt vaak helemaal geen interface, maar een koppeling. Voorbeelden van hoe dat uitpakt staan in onze cases.
Vier vormen, vier verschillende rekeningen
Een website met slimme formulieren is publiek en levert aanvragen gestructureerd aan. Een klantportaal is een ingelogd deel van je site met status en documenten. Een webapp is een volledige applicatie in de browser, ook op mobiel. Een native app installeert de gebruiker uit de App Store of Play Store. Het onderhoud loopt in diezelfde volgorde op, van laag naar hoog. De tabel hieronder laat per vorm zien wat de kosten vooral opdrijft.
| Vorm | Wat de kosten opdrijft | Wanneer dit klopt |
|---|---|---|
| Website met slimme formulieren | De formulieren en de koppeling met je administratie | Het proces begint bij een aanvraag |
| Klantportaal | Inloggen, rechten en de koppeling met je systemen | Klanten willen zelf zien hoe het staat |
| Webapp op maat | Elke rol, uitzondering en koppeling die je vanaf dag een wilt | Je proces is je product |
| Native app | Twee platformen, de eisen van de app-winkels en onderhoud bij elke systeemupdate | Pushmeldingen, camera, offline gebruik of hardware |
Merk op dat de sprong van portaal naar app niet alleen in de bouwsom zit, maar vooral in de staart. Elke vorm daaronder onderhoud je met een website-ritme. Een app onderhoud je met een productritme.
Wat native echt met zich meebrengt
Een native app publiceren kost een Apple Developer Program-account van 99 dollar per jaar en een eenmalige registratie van 25 dollar bij Google Play. Dat is het goedkoopste deel. Elke release gaat door een beoordeling, elk platform heeft zijn eigen richtlijnen, en je gebruikers moeten daadwerkelijk updaten. Zelfs met een cross-platform framework test je op twee ecosystemen.
Een native app verdient zichzelf terug als je pushmeldingen, camera, locatie op de achtergrond, offline gebruik of hardware nodig hebt, of als gebruikers hem dagelijks openen. Heb je dat niet, dan is een app vaak een duurdere verpakking van een website die je toch al moet bouwen.
De meeste bedrijven willen geen app. Ze willen dat een klant iets zelf kan zonder te bellen.
Waar het geld heen gaat bij maatwerk
Bij een maatwerkplatform gaat het budget zelden op aan schermen. Het gaat op aan beslissingen en aan koppelingen. Grofweg vier posten: het scherp krijgen van de scope, het ontwerp van de flows en de datastructuur, het bouwen, en de integraties met wat je al gebruikt. Die laatste post is de grootste onbekende, want die hangt af van systemen waar jij geen eigenaar van bent.
Reken daarnaast op beheer. Een platform dat niemand bijhoudt is binnen twee jaar een beveiligingsrisico en binnen drie jaar een blok aan het been. Plan er structureel budget en aandacht voor in, of bouw het niet.
Vier signalen dat maatwerk zich terugverdient
- Er gaan elke week uren op aan handmatig overtypen tussen systemen.
- De spreadsheet die alles bij elkaar houdt, kent maar een persoon echt.
- Klanten bellen voor informatie die ergens al staat.
- Een nieuwe klant of locatie erbij betekent meer werk, geen schaalvoordeel.
Een simpele rekensom helpt om het gesprek eerlijk te houden. Tel de uren handwerk per week, vermenigvuldig met een intern uurtarief en met het aantal werkweken per jaar. Zet dat naast de bouwsom plus het beheer. Ligt de terugverdientijd onder de twee jaar, dan is dit het gesprek waard. Ligt hij op vijf jaar, dan is het waarschijnlijk een proces dat je eerst moet vereenvoudigen.
Begin bij de kleinste versie die een proces echt oplost
De duurste manier om een platform te bouwen is alles tegelijk. De goedkoopste is een eerste versie die precies een proces volledig afmaakt, voor echte gebruikers, in weken in plaats van kwartalen. Daarna bouw je verder op wat je hebt geleerd, in plaats van op wat je in een workshop had bedacht.
Bij ons landen focussites meestal in zes tot acht weken; platformen en winkels doorgaans in drie tot vier maanden. Wat er komt kijken bij een webapplicatie of app laten maken, van afbakening tot uitbrengen, staat op de dienstpagina; twijfel je nog over de vorm, dan begint het bij digitale strategie. Wat een traject kost hangt af van de vorm die je kiest en het aantal koppelingen; de tabel hierboven geeft de bandbreedtes. Verkoop je producten in plaats van tijd of expertise, dan is de vergelijking een andere: lees dan webshop laten maken. Een concreet voorbeeld van een platformvraag met een duidelijke opbrengst is een boekingssysteem op je eigen site.
Veelgestelde vragen
Webapp of native app?
Kies native als je pushmeldingen, camera, achtergrondlocatie, offline gebruik of hardware nodig hebt, of als mensen je product dagelijks gebruiken. In alle andere gevallen is een webapp sneller live, goedkoper te onderhouden en direct te delen via een link. Je kunt later altijd nog native bouwen op een platform dat zich al bewezen heeft.
Wat kost een eerste versie?
Dat hangt vooral af van het aantal koppelingen en gebruikersrollen; de tabel hierboven laat per vorm zien wat de kosten opdrijft. De grootste kostenpost is nooit het aantal schermen, maar het aantal uitzonderingen dat je vanaf dag een wilt ondersteunen.
Hoe lang duurt het voordat we iets kunnen gebruiken?
Bij een strak afgebakende eerste versie werken echte gebruikers doorgaans binnen drie tot vier maanden in het systeem. Duurt het langer, dan is de scope meestal het probleem en niet het bouwtempo.