Mobiele app of webapp? Een eerlijke beslisgids voor het MKB

Bijna elke week vertelt iemand ons dat hij een app nodig heeft. Meestal hebben ze het al voor zich gezien — een pictogram op een telefoon, iets dat klanten downloaden, misschien een klein badgetje met het aantal meldingen. En bijna even vaak blijkt na een kwartiertje gesprek dat ze helemaal geen app nodig hebben. Ze hebben iets nodig dat prachtig werkt op een telefoon, en dat is iets compleet anders — goedkoper, sneller en veel minder kans om stof te vergaren in een appstore die niemand bezoekt.

Het woord "app" heeft stilletjes drie of vier heel verschillende producten opgeslokt. Als iemand het zegt, kan hij een native app bedoelen die u downloadt, een website die zich als een app gedraagt, een interne tool voor het eigen personeel, of gewoon "een moderne versie van mijn bedrijf op een scherm." Hier verkeerd kiezen is duur — niet omdat de verkeerde keuze moeilijk te bouwen is, maar omdat het u vastlegt op maandenlange kosten en onderhoud die u niet nodig had.

Dit is dus de gids die we elke ondernemer voor dat eerste gesprek hadden gegund. Geen hype over welk platform aan het winnen is, geen gedoe alsof native apps altijd de prestigieuze keuze zijn. Gewoon een nuchtere blik op wat de twee opties werkelijk zijn, wat ze kosten, en een eenvoudige manier om te bepalen welke uw bedrijf nodig heeft — als het er al een nodig heeft.

Ontwar eerst wat u eigenlijk bedoelt met "app"

Voordat u kunt kiezen, moet u weten wat er op de kaart staat. Een mobiele app — het native type — is software die een gebruiker installeert uit de App Store of Google Play. Hij staat op de telefoon, krijgt een pictogram en kan diep in het apparaat reiken: camera, GPS, pushmeldingen, offline opslag, inloggen met een vingerafdruk. Een webapp is een website die meer doet dan informatie tonen — hij laat mensen dingen doen: inloggen, boeken, betalen, een account beheren. U opent hem in een browser en er valt niets te downloaden.

Daartussenin zit een derde optie waarvan de meeste mensen de naam nog nooit hebben gehoord: de progressive web app, of PWA. Het is een webapp die zo gebouwd is dat hij "aan het startscherm toegevoegd" kan worden, schermvullend draait met een eigen pictogram, offline werkt en op de meeste apparaten meldingen kan sturen. Voor een enorm deel van het MKB is dit de gulden middenweg die niemand noemde — hij voelt voor de klant als een app, maar wordt gebouwd en onderhouden als een website.

Houd deze drie scherp in uw hoofd en de helft van de verwarring verdwijnt. Meestal is de eerlijke vraag niet "native of web?" — maar "hoe app-achtig moet dit echt aanvoelen, en is dat de prijs waard?"

De verschillen die er voor een bedrijf echt toe doen

U vindt honderd artikelen die deze twee op technische gronden vergelijken. De meeste zijn geschreven voor ontwikkelaars en missen waar een ondernemer werkelijk om geeft. Laten we de frameworkoorlogen dus overslaan en het hebben over de vier dingen die veranderen hoe uw bedrijf draait.

Hoe mensen erbij komen

Een webapp leeft op een link. U kunt hem in een e-mail zetten, in een sms, in een QR-code op tafel, in een Google-zoekresultaat. Een klant gebruikt hem twee seconden na het klikken. Een native app leeft achter een download — uw klant moet hem genoeg willen om naar een store te gaan, uw naam te zoeken, hem te installeren en te openen. Die kloof is meedogenloos. Voor een bedrijf waar de meeste mensen af en toe mee te maken hebben, is de download vaak de hele reden dat een app faalt.

Wat het werkelijk kan

Native wint nog steeds op pure kracht. Heeft u keiharde offline werking nodig, zwaar camera- of sensorwerk, vloeiende high-performance graphics, of meldingen die absoluut moeten aankomen, dan is native de veiligere keuze. Maar de kloof is dramatisch kleiner geworden. Een moderne webapp kan betalingen verwerken, de camera gebruiken, uw locatie vinden, offline werken en op de meeste telefoons pushmeldingen sturen. De eerlijke vraag is of uw bedrijf werkelijk leunt op de paar dingen die alleen native goed doet.

Wat het kost om te bouwen en draaiende te houden

Hier is de kloof het breedst, en hier worden ondernemers verrast. Een webapp is één codebase die overal draait met een browser. Een native app betekent, goed gedaan, vaak bouwen en onderhouden voor twee platforms, plus het beoordelingsproces van de appstore, plus doorlopende updates telkens als Apple of Google de regels verandert. De bouw is duurder; het onderhoud is het deel waar niemand u voor waarschuwt. Een app is niet iets dat u afmaakt — het is iets dat u voedt.

Hoeveel controle u houdt

Met een webapp brengt u een wijziging uit en staat hij binnen enkele minuten live. Met een native app wacht elke update in een beoordelingswachtrij, en de store kan hem afwijzen, een deel van elke verkoop opeisen, of zijn beleid onder u veranderen. U huurt ruimte op het platform van iemand anders. Voor sommige bedrijven is die ruil het waard. Voor veel andere is de vrijheid van "het is gewoon een website, we updaten hem wanneer we willen" meer waard dan de glans.

Wanneer een native mobiele app echt de juiste keuze is

Native apps zijn geen valstrik — het is een krachtig instrument dat verkeerd is voor de meeste mkb-bedrijven en precies goed voor enkele. Hier is wanneer de extra kosten en lock-in zichzelf terugverdienen, eerlijk en zonder verkooppraatjes.

• Mensen gebruiken hem voortdurend — dagelijks of bijna dagelijks. De downloadkosten worden vele malen terugverdiend door frequent, trouw gebruik.
• U leunt zwaar op apparaatfuncties: continue GPS, zwaar camerawerk, Bluetooth-hardware, betrouwbare offline werking op plekken zonder bereik.
• Meldingen zijn de kern van het product, geen leuk extraatje, en ze moeten betrouwbaar op elk apparaat aankomen.
• De prestaties moeten vlekkeloos zijn — snel bewegende graphics, games, realtime interactie waarbij een halve seconde vertraging een dealbreaker is.
• In de App Store staan is op zichzelf deel van het vertrouwen of het marketingverhaal dat uw klanten verwachten.

Let op het thema: native verdient zijn plek wanneer de app veel wordt gebruikt, door mensen die zich al aan u hebben verbonden, en wanneer hij leunt op de hardware van de telefoon op manieren die de browser nog niet kan evenaren. Een buitendienst-app die uw eigen ploeg veertig keer per dag opent, is een perfecte native kandidaat. Een boekingspagina die een klant twee keer per jaar aanraakt niet.

Wanneer een webapp de slimmere, goedkopere keuze is

Voor de meeste kleine en middelgrote bedrijven is dit het antwoord — en het is geen compromis, het is de juiste keuze. Een webapp schittert precies waar native worstelt: overal waar bereik belangrijker is dan pure kracht, en overal waar u snel moet handelen en vaak dingen moet veranderen.

Ga web-first wanneer mensen het ding af en toe gebruiken in plaats van dagelijks, wanneer u klanten binnen wilt halen zonder de drempel van een download, wanneer budget en snelheid tellen, of wanneer u nog niet zeker weet of het idee aanslaat. Dat laatste punt wordt onderschat. Een webapp is de perfecte manier om te testen of iemand uw idee wil, voordat u zich vastlegt op de kosten van native gaan. U kunt de native app altijd later bouwen, zodra de vraag echt is en u precies kunt zien welke functies hem verdienen.

Een kort verhaal: de praktijk die om een app vroeg

Een fysiotherapiepraktijk kwam bij ons, overtuigd dat ze een mobiele app nodig hadden. Een concurrent verderop had er een, en het voelde als achterop raken om er geen te hebben. Hun beeld was helder: patiënten zouden de app downloaden, afspraken boeken, hun oefenschema's bekijken en herinneringen krijgen. Ze hadden er al half voor begroot en zich schrap gezet voor de kosten.

Dus stelden we de vraag die we altijd stellen: hoe vaak zal een patiënt dit werkelijk openen? Het eerlijke antwoord was een handvol keren rond een behandeltraject — boeken, even naar de oefeningen kijken, eraan herinnerd worden, misschien maanden later opnieuw boeken. Dat is geen dagelijks gebruik. Dat is incidenteel gebruik. En incidenteel gebruik is precies waar de downloaddrempel een app stilletjes om zeep helpt. We schetsten de waarschijnlijke afloop: een paar honderd euro bouwkosten, dan patiënten die hem nooit installeren, en een receptie die nog steeds boekingen per telefoon aanneemt omdat de app ongebruikt bleef.

Wat we in plaats daarvan bouwden

We bouwden een webapp — een progressive. Patiënten openen hem vanuit een link in hun bevestigingsbericht: geen download, geen store, geen accountdrempel om te beginnen. Ze kunnen boeken en opnieuw boeken, hun oefenschema met video's bekijken, en automatische herinneringen ontvangen die no-shows terugdringen. Wie het appgevoel wil, kan hem met één tik aan het startscherm toevoegen, en vanaf dan opent hij schermvullend met het pictogram van de praktijk, precies als een native app. Voor de patiënt ís het simpelweg de app.

Hoe het uitpakte

De cijfers hier zijn illustratief, maar de vorm is wat we keer op keer zien. Het kostte een fractie van de native bouw waar ze zich schrap voor hadden gezet, en veel minder om draaiende te houden — geen twee platforms, geen storebeoordelingen, geen kwartaalstress wanneer een besturingssysteem update. Omdat er niets te installeren viel, gebruikten patiënten hem vanaf dag één; de adoptie zat niet achter een download die niemand voltooit. Herinneringen verminderden binnen een paar maanden merkbaar de no-shows. En de praktijk hield de controle: toen ze een betaalstap wilden toevoegen, stond die diezelfde week live, niet vast in een beoordelingswachtrij.

De eerlijke voetnoot: als patiënten over een jaar de app voortdurend openen en om diepere offline functies vragen, kan een native app echt zijn plek verdienen. Maar dan wordt die beslissing genomen op basis van bewijs, niet op het pictogram van een concurrent. Ze weten dat het de moeite waard is voordat ze ervoor betalen.

Een eenvoudig kader om zelf te beslissen

U hebt geen consultant nodig om dit ruwweg goed te krijgen. Loop uw idee langs vier vragen, op volgorde. Het eerste "ja" dat echt past, vertelt u het meeste van wat u moet weten.

1. 1
   Hoe vaak zal één persoon hem gebruiken?

   Dagelijks of bijna dagelijks wijst richting native. Af en toe — wekelijks, maandelijks, een paar keer per jaar — wijst stevig richting web.
2. 2
   Heeft het echt de hardware van de telefoon nodig?

   Zwaar offline gebruik, continue GPS, Bluetooth-apparaten, intensief camerawerk? Dat is een native signaal. "Het zou leuk zijn om de camera één keer te gebruiken" niet — dat handelt het web prima af.
3. 3
   Hoe snel en hoe vaak gaat u hem veranderen?

   Als u voortdurend zult bijschaven en updaten, of u test het idee nog, dan zijn de directe updates en het ontbreken van poortwachters een groot voordeel van web.
4. 4
   Wat is uw echte budget — om te bouwen én te onderhouden?

   Wees eerlijk over dat tweede getal. Als doorlopend onderhoud voor twee platforms u zou belasten, begin dan met web. U kunt later bewust naar native overstappen, wanneer de zaak is bewezen.

Een opmerking over interne tools — een heel andere vraag

Alles hierboven gaat ervan uit dat u voor klanten bouwt. Bouwt u voor uw eigen team, dan verschuift de rekensom. Uw personeel installeert met plezier iets dat ze de hele dag voor het werk gebruiken — de downloaddrempel die een consumenten-app om zeep helpt, doet er nauwelijks toe wanneer het gebruik van de tool het werk is. Een interne buitendienst- of magazijn-app kan dus een sterke native zaak hebben waar een klantgerichte dat niet zou hebben.

Zelfs dan wint web vaker dan mensen verwachten. Een webgebaseerde interne tool werkt op welk apparaat uw personeel ook al bij zich draagt, vereist geen installatie over een vloot telefoons, en is voor iedereen geüpdatet op het moment dat u publiceert. Tenzij u werkelijk afhankelijk bent van offline werking of diepe hardwaretoegang, is een interne webapp meestal de snellere, goedkopere, minder pijnlijke weg — dezelfde logica als eerder, alleen met de gebruiksaannames omgedraaid.

Veelgestelde vragen