Een app is geen kleine website. Dat is precies waarom het werkt.

De eerlijkste vraag om mee te beginnen is of je wel een app nodig hebt. In veruit de meeste gesprekken die Plaincodelab voert, blijkt de vraag achter de vraag met een goede website of een webapplicatie beter opgelost te worden. Dat is geen bescheidenheid maar rekenwerk: een app kost meer om te bouwen, meer om te onderhouden en vraagt van je klant dat hij iets installeert. Die drempel is hoger dan mensen denken. Wie een app maakt voor iets wat één keer per jaar gebeurt, bouwt een pictogram dat op de derde pagina van een telefoon staat te verstoffen.

Een app verdient zichzelf terug op herhaling. Als iemand jouw dienst wekelijks gebruikt, als je meldingen wilt sturen die daadwerkelijk gelezen worden, als er offline gewerkt moet worden of als je toegang nodig hebt tot camera, locatie, bluetooth of biometrie, dan wordt het interessant. Een sportschool met leden die vier keer per week inchecken, een installatiebedrijf met monteurs die op zolders zonder bereik werkbonnen invullen, een groothandel met vertegenwoordigers die onderweg bestellingen opnemen: dat zijn situaties waarin een app werkelijk iets toevoegt dat een website niet kan.

Er is nog een derde categorie die vaak vergeten wordt: de interne app. Die staat niet in een store, wordt niet gedownload door consumenten en heeft geen marketing nodig. Hij vervangt een stapel formulieren, een spreadsheet die niemand meer begrijpt of een pakket waar je maandelijks voor betaalt en dat toch niet doet wat jij wilt. Interne apps zijn vaak het meest rendabel, omdat de winst direct meetbaar is in uren die je niet meer kwijt bent.

Plaincodelab begint daarom altijd met de vraag wat er precies moet gebeuren, hoe vaak en door wie. Pas als dat scherp is, volgt de keuze voor de vorm. Soms is dat een app, soms een webapplicatie met een pictogram op het beginscherm, soms een uitbreiding van de site die je al hebt. In alle gevallen krijg je die afweging uitgelegd voordat er een euro aan bouw wordt uitgegeven.

Er zijn vier manieren om een app te bouwen, en het verschil ertussen bepaalt je budget en wat er later mogelijk is. Ze worden vaak door elkaar gebruikt, ook door bureaus, wat tot offertes leidt die niet vergelijkbaar zijn. Hieronder staat per vorm wat het is, wat het kost en waar de grens ligt.

Native betekent dat je twee losse apps bouwt: één in Swift voor iOS en één in Kotlin voor Android. Je krijgt de beste prestaties, de nieuwste mogelijkheden op de dag dat Apple of Google ze uitbrengt en een app die precies aanvoelt zoals gebruikers van dat platform gewend zijn. Je betaalt dat met twee keer bouwen en twee keer onderhouden. Voor de meeste bedrijfsapps is dat overkill; voor apps waarin zware graphics, camera-verwerking of complexe animatie centraal staan, is het de juiste keuze.

Cross-platform betekent één codebase voor beide platforms, tegenwoordig meestal met React Native of Flutter. Je levert twee echte apps op die in de stores staan, met toegang tot camera, meldingen, locatie en de rest, maar je schrijft het werk één keer. In de praktijk deelt zo'n project tachtig tot negentig procent van de code; de rest is platformspecifiek. Voor verreweg de meeste opdrachten is dit de verstandigste route, en het is dan ook wat Plaincodelab het vaakst bouwt.

Een webapp draait in de browser. Geen store, geen installatie, geen goedkeuring van Apple. Je stuurt een link en iedereen kan meteen aan de slag, op elk apparaat. Voor interne toepassingen — planning, urenregistratie, dossiers, dashboards — is dit vrijwel altijd de snelste en goedkoopste weg. De grens ligt bij hardwaretoegang: sommige dingen kan een browser niet of half.

Een PWA is een webapp met een schil eromheen: hij krijgt een pictogram op het beginscherm, kan offline werken en kan meldingen sturen. Het is het compromis tussen bereik en kosten. Op Android werkt een PWA vrijwel als een echte app; op iOS zijn de mogelijkheden beperkter, al is dat de laatste jaren verbeterd. Voor een bezorgdienst, een klantportaal of een intern hulpmiddel is een PWA vaak genoeg.

Een app bouwen is geen rechte lijn van briefing naar oplevering. Het is een reeks beslissingen waarbij elke stap de volgende goedkoper of duurder maakt. Plaincodelab werkt daarom in korte ronden met steeds een werkende versie aan het eind van een ronde, zodat je niet aan het eind van het traject ontdekt dat iets anders had gemoeten.

Stap één is uitzoeken. Wie gebruikt de app, hoe vaak, in welke omstandigheden en wat gebeurt er nu zonder app. Dat laatste is belangrijker dan het klinkt: de huidige werkwijze bevat altijd uitzonderingen die niemand spontaan noemt, maar die de app wel moet aankunnen. Deze stap eindigt met een lijst functies, verdeeld in wat er in de eerste versie moet en wat kan wachten.

Stap twee is ontwerp. Geen mooie plaatjes maar schermen die kloppen: welke informatie staat waar, wat gebeurt er bij een fout, hoe ziet het eruit met echte gegevens in plaats van voorbeelddata. Plaincodelab levert dit als klikbaar prototype, zodat je het op je eigen telefoon kunt doorlopen voordat er iets gebouwd is. Wijzigingen kosten hier minuten; later kosten ze dagen.

Stap drie is de bouw van het fundament: de gegevensstructuur, de koppelingen met systemen die je al gebruikt, inloggen en rechten. Dit is het deel dat je niet ziet en dat bepaalt of de app later nog uit te breiden is. Wie hier bezuinigt, betaalt dat met rente terug.

Stap vier is de app zelf, scherm voor scherm, met onderweg steeds een versie die je op je eigen toestel kunt installeren. Stap vijf is testen met echte gebruikers in echte omstandigheden — een monteur op een dak, een medewerker aan de balie tijdens de spits. Daar komen de dingen uit die je achter een bureau nooit bedenkt.

Stap zes is de livegang: indienen bij de App Store en Google Play, of uitrollen binnen je eigen organisatie. Beide stores beoordelen een app voordat hij verschijnt; hoe lang dat duurt verschilt per inzending. Bij de indiening horen vermeldingsteksten, schermafbeeldingen en een privacybeleid dat beide stores verplicht stellen.

Prijzen voor apps lopen zo ver uiteen dat het woord alleen weinig zegt. Een intern hulpmiddel met drie schermen en een koppeling is een ander project dan een consumenten-app met accounts, betalingen, meldingen en een beheeromgeving. Wat de prijs bepaalt is zelden het aantal schermen, maar het aantal regels: wat mag wie, wat gebeurt er bij een uitzondering, en met welke systemen moet het praten.

De onderlinge verhouding is wel voorspelbaar. Een eenvoudige webapp of PWA voor intern gebruik is de lichtste vorm: geen store-traject en één omgeving om te onderhouden. Een cross-platform app in beide stores, met accounts, meldingen en een koppeling naar een bestaand systeem, vraagt duidelijk meer. Volledig native, met twee losse codebases, vraagt daar nog eens boven omdat het werk zich verdubbelt. Wat dat voor een concreet plan betekent, ligt vast voordat er gebouwd wordt — inclusief wat er wel en niet in die eerste versie zit, zodat de rekening onderweg niet ongemerkt oploopt.

Wat je prijs vooral opdrijft: betalingen in de app, meerdere gebruikersrollen met verschillende rechten, offline werken met synchronisatie achteraf, koppelingen met systemen die geen moderne interface hebben, en alles wat met documenten of ondertekening te maken heeft. Wat de prijs juist drukt: beginnen met de kern en de rest bewust uitstellen, hergebruik van componenten die PCL al gebouwd heeft, en één helder besluitpunt in plaats van drie partijen die meebeslissen.

Reken daarnaast op vaste kosten na de oplevering. Apple rekent periodiek voor een ontwikkelaarsaccount, Google eenmalig. Daarbovenop komen hosting, bewaking en het onderhoud dat nodig is omdat besturingssystemen blijven veranderen. Een app die niemand onderhoudt, werkt op een gegeven moment niet meer — dat is geen dreigement maar hoe de platforms werken.

Hoe lang een app duurt, hangt volledig af van wat hij moet doen. Plaincodelab noemt daarom geen gemiddelden en geen standaardtermijnen: die zeggen niets over jouw project en scheppen verwachtingen die daarna bijgesteld moeten worden. Zodra duidelijk is wat er gebouwd wordt, wordt de planning samen met de prijs vastgelegd — en dat gebeurt vóórdat er iets gebouwd wordt, niet onderweg.

Wat het tempo bepaalt is bijna nooit het programmeren zelf. Het zijn de besluiten: akkoord op het ontwerp, aanleveren van logo, teksten en beeld, toegang tot systemen waarmee gekoppeld moet worden, en het aanmaken van de ontwikkelaarsaccounts op naam van jouw bedrijf. In projecten die uitlopen, ligt de vertraging in de meeste gevallen in die kolom en niet in de code.

Daarnaast zit er een deel in het traject waar niemand invloed op heeft: de beoordeling door Apple en Google. Hoe lang die duurt, verschilt per inzending en per periode, en is met harder werken niet in te korten. Dat wordt in de planning als apart moment meegenomen in plaats van weggemoffeld in de bouwtijd.

Wat het traject korter maakt: beginnen met een kleinere eerste versie, één beslisser aanwijzen die knopen doorhakt, testgebruikers vooraf regelen, en de vraag wie de app straks beheert meteen beantwoorden. Wat het langer maakt: functies die tijdens de bouw worden toegevoegd, koppelingen met partijen die traag reageren, en teksten of beeld die pas op het laatste moment komen.

Plaincodelab werkt daarom met een planning in twee kolommen — wat PCL doet en wat jij doet — zodat vanaf het begin zichtbaar is welke stap op wie wacht. Verschuift er iets in jouw kolom, dan zie je meteen wat dat betekent, in plaats van dat het pas aan het eind opvalt.

Techniek is een middel, geen doel. De keuze voor een framework moet je later nog kunnen uitleggen aan de volgende ontwikkelaar, en die moet er dan nog mensen voor kunnen vinden. Plaincodelab kiest daarom bewust voor gereedschap met een grote gemeenschap eromheen en zonder eigenaardigheden die alleen door één bureau te onderhouden zijn.

Welke gereedschapskist het wordt, hangt af van wat de app moet doen. Voor de meeste bedrijfsapps volstaat een cross-platform opzet met één codebase en echte native componenten, aangevuld met native code waar het besturingssysteem daarom vraagt: een specifieke bluetooth-koppeling, een scanner die snel moet zijn, een achtergrondtaak die streng bewaakt wordt. Draait alles om beweging, beeld of prestaties, dan is volledig native de betere keuze. Plaincodelab legt die afweging per project vast in plaats van elk project in dezelfde vorm te duwen.

Achter de app zit een backend: een database, een programmeerinterface waarmee de app praat, en een beheeromgeving waarin jij dingen kunt aanpassen zonder een ontwikkelaar te bellen. Welke taal en database daaronder liggen, hangt af van wat er moet gebeuren; een relationele database ligt voor de hand zodra gegevens verbanden hebben. Waar dat draait, is een keuze die je zelf maakt: voor Europese bedrijven ligt een server binnen de EU voor de hand. Relationeel omdat bedrijfsgegevens verbanden hebben — een order hoort bij een klant, een factuur bij een order — en die verbanden wil je door de database laten bewaken en niet door goede bedoelingen.

Verder hoort er een testomgeving bij die los staat van de echte, een bouwstraat die bij elke wijziging automatisch controleert of alles nog werkt, en foutmelding op afstand zodat PCL het weet voordat jouw klant belt. Die dingen zien er in een offerte uit als overhead. Ze zijn het verschil tussen een app die je durft aan te passen en een app waar iedereen bang voor is.

Bij een website beslist iemand in enkele seconden of hij blijft. Bij een app beslist hij bij de derde keer openen of hij hem houdt. Dat verschil bepaalt hoe je ontwerpt: niet op de eerste indruk, maar op de tiende. Een scherm dat de eerste keer indrukwekkend is en daarna elke dag twee tikken te veel kost, verliest het van een scherm dat saai oogt en meteen doet wat je wilt.

Plaincodelab ontwerpt vanuit de handeling die het vaakst gebeurt. Die krijgt de grootste knop, de kortste weg en de duim-vriendelijkste plek op het scherm — onderaan, waar je hand al is, niet bovenin waar ontwerpers hem graag zetten. Alles wat zelden gebeurt, mag een tik dieper. Dat klinkt vanzelfsprekend, maar de meeste apps zijn ingedeeld naar de structuur van het bedrijf en niet naar de dag van de gebruiker.

Daarnaast telt de staat waarin de app verkeert. Een app is bijna nooit netjes gevuld: er is geen verbinding, de lijst is leeg, het laden duurt lang, de invoer klopt niet, de sessie is verlopen. Voor elk van die situaties hoort een scherm te bestaan dat uitlegt wat er aan de hand is en wat je nu kunt doen. Dit is precies het deel dat in goedkope trajecten overgeslagen wordt, en precies het deel waarop gebruikers afhaken.

Toegankelijkheid hoort daar bij. Voldoende contrast, tekst die meegroeit als iemand de systeeminstelling groter zet, aanraakvlakken die groot genoeg zijn, labels die een schermlezer kan voorlezen, en beweging die uit gaat als iemand in zijn instellingen heeft aangegeven daar last van te hebben. Voor publieke en semi-publieke organisaties is dat een wettelijke eis; voor de rest is het gewoon fatsoenlijk werk, en het maakt de app ook voor iedereen zonder beperking prettiger.

Beweging gebruikt PCL functioneel: een overgang die laat zien waar een scherm vandaan komt, een lijst die netjes opbouwt, een knop die bevestigt dat de tik is aangekomen. Animatie die alleen laat zien dat de bouwer animatie kan, kost accuduur en aandacht. De regel is simpel: als de beweging weggehaald kan worden zonder dat iemand iets mist, moet hij weg.

Een app die op zichzelf staat, levert dubbel werk op. De winst zit in de koppeling: bestellingen die rechtstreeks in je pakket landen, uren die vanzelf op de factuur komen, voorraad die klopt omdat er één bron van waarheid is. Bij vrijwel elk project van Plaincodelab is het koppelvlak het inhoudelijk lastigste onderdeel — en het onderdeel dat de meeste tijd terugverdient.

Betalingen lopen doorgaans via Mollie, Stripe of Adyen, met iDEAL, creditcard, Bancontact en achteraf betalen als opties. Belangrijk om te weten: verkoop je digitale zaken binnen de app — een abonnement, extra functies, tegoed — dan verplichten Apple en Google in veel gevallen hun eigen afrekensysteem, met een commissie die daarbij hoort. Verkoop je fysieke producten of diensten die buiten de app geleverd worden, dan mag je gewoon je eigen betaalprovider gebruiken. Die grens verkeerd inschatten is een van de vaakst voorkomende redenen voor afwijzing in de App Store.

Verder koppelt PCL met wat er al draait: boekhoudpakketten zoals Exact, Moneybird of Twinfield, planning- en urensystemen, voorraad- en kassasystemen, CRM's, agenda's, en de mailsystemen waar bevestigingen uit moeten komen. Waar een leverancier een moderne interface heeft, gaat dat vlot. Waar dat niet zo is — en dat komt in het midden- en kleinbedrijf regelmatig voor — bouwt PCL een tussenlaag die de rommel opvangt en netjes doorgeeft, zodat de app schoon blijft.

Wat de telefoon zelf te bieden heeft, hoort ook in deze lijst: camera en scannen van barcodes of documenten, locatie en routes, meldingen, agenda, contacten, bestanden, bluetooth voor apparatuur, biometrisch inloggen met gezicht of vinger, en offline opslag met synchronisatie zodra er weer bereik is. Dat laatste is bij buitendienst vaak de reden dat het een app wordt en geen website.

Bij elke koppeling hoort de vraag wat er gebeurt als de andere kant plat ligt. Een app die vastloopt omdat een extern systeem niet antwoordt, is een app die op het slechtst mogelijke moment stukgaat. PCL bouwt daarom altijd een vangnet: opnieuw proberen, in de wachtrij zetten, en een duidelijke melding aan de gebruiker in plaats van een draaiend rondje zonder einde.

Een app bouwen is de helft van het werk; hem gepubliceerd krijgen is de andere helft. Apple beoordeelt elke app handmatig voordat hij in de App Store verschijnt, Google doet dat grotendeels geautomatiseerd met steekproeven. Beide hebben richtlijnen die niet onderhandelbaar zijn en die regelmatig veranderen. Wie ze kent, komt er meestal in één ronde doorheen; wie ze negeert, loopt tegen afwijzingen aan.

De afwijzingen die Plaincodelab het vaakst ziet, zijn steeds dezelfde. Een app die eigenlijk alleen een website in een schil is, zonder eigen functionaliteit. Een aanmeldscherm dat verplicht is terwijl de app zonder account ook zinvol zou zijn. Een verplicht account zonder de mogelijkheid dat account in de app weer te verwijderen — dat laatste is sinds een paar jaar een harde eis. Digitale aankopen die buiten het afrekensysteem van de store om gaan. Toestemming vragen voor camera of locatie zonder uit te leggen waarom. En incomplete of misleidende vermeldingsteksten en schermafbeeldingen.

Voor de indiening zelf heb je meer nodig dan het bestand: een pictogram in de juiste maten, schermafbeeldingen per toesteltype, een korte en een lange omschrijving, trefwoorden, een leeftijdsclassificatie, een privacybeleid op een openbare pagina, en bij Apple een ingevuld privacylabel waarin per soort gegeven staat wat je verzamelt en waarvoor. Dat label moet kloppen met wat de app werkelijk doet; het is geen marketingtekst.

Verstandig is om testversies eerst te verspreiden via TestFlight bij Apple en de testkanalen van Google Play. Een kleine groep echte gebruikers vindt in de praktijk meer dan een testafdeling. Pas als daar niets meer uitkomt, gaat de app naar de openbare beoordeling.

En dan is er nog het onderdeel dat mensen vergeten: de vermelding zelf is vindbaarheid. De naam, de ondertitel en de eerste regels bepalen of iemand die in de store zoekt jouw app tegenkomt. Dat is een eigen vakgebied — App Store Optimalisatie — en het loont om daar bij de indiening al over na te denken in plaats van er later achter te komen.

Een app zit dichter op de gebruiker dan een website. Hij staat op een persoonlijk apparaat, mag vaak bij camera en locatie, en kan gegevens bewaren als het toestel offline is. Daarmee wordt privacy geen bijzaak maar een ontwerpvraag die vanaf dag één meespeelt. De AVG noemt dat privacy by design, en in de praktijk komt het neer op één gewoonte: niets verzamelen wat je niet nodig hebt.

Concreet betekent dat een korte lijst afspraken. Vraag toestemming op het moment dat de functie gebruikt wordt en leg in één zin uit waarom — niet allemaal tegelijk bij het eerste openen. Bewaar gegevens op servers binnen de EU. Versleutel het verkeer tussen app en server en versleutel gevoelige gegevens ook op het toestel zelf. Sla wachtwoorden nooit op als tekst maar als hash met een modern algoritme. Log wie wat wanneer heeft gezien wanneer het om persoonsgegevens gaat. En spreek af hoe lang gegevens bewaard blijven, met een knop om ze te verwijderen.

Voor apps die met bijzondere gegevens werken — gezondheid, kinderen, financiën, biometrie — geldt een zwaarder regime: vaak een gegevensbeschermingseffectbeoordeling vooraf en strengere afspraken met iedereen die meekijkt. Werk je met externe partijen zoals een hostingpartij of een analysedienst, dan hoort daar een verwerkersovereenkomst bij. Die documenten horen bij het project te zitten in plaats van bij jou over de schutting te worden gegooid.

Beveiliging is het tweede spoor. Inloggen met tweestapsverificatie waar dat kan, sessies die verlopen, rechten die per rol vastliggen en aan de serverkant gecontroleerd worden — nooit alleen in de app, want alles wat op een toestel staat kan uitgelezen worden. Sleutels en wachtwoorden horen niet in de app-code; die worden in een kluis bewaard en via de server geregeld. Bijwerken van externe onderdelen gebeurt periodiek, want de meeste lekken komen niet uit eigen code maar uit een verouderd onderdeel dat jarenlang niemand aanraakte.

Tot slot: wees eerlijk in de winkel. Beide stores vragen je om te verklaren welke gegevens je verzamelt en of je die deelt of gebruikt om mensen te volgen. Een verklaring die niet klopt is niet alleen een afwijzing waard, het is ook een toezichtsrisico. Het eerlijke antwoord is meestal gunstiger dan mensen denken: apps die weinig verzamelen, scoren beter bij gebruikers die daar tegenwoordig op letten.

De dag dat een app in de store staat, begint het echte werk. Apple en Google brengen geregeld een nieuwe versie van hun besturingssysteem uit, wijzigen hun richtlijnen en zetten oudere manieren van werken uit. Een app die niet meegaat, valt op een gegeven moment uit de store of stopt met werken op nieuwe toestellen. Onderhoud is bij apps dus geen luxe maar een voorwaarde om te blijven bestaan.

Onderhoud hoort daarom vooraf geregeld te zijn en dekt drie dingen: bijhouden van het platform en de gebruikte onderdelen, in de gaten houden of alles draait, en het oplossen van storingen binnen een afgesproken reactietijd. Daarnaast hoort er budget te staan voor doorontwikkeling, want een app die niet verandert, verandert vanzelf in een app die niemand meer opent.

Meten hoort daar onlosmakelijk bij, maar dan wel netjes. Niet elke tik doorsturen naar een advertentienetwerk, wel weten hoeveel mensen een handeling afronden, waar ze afhaken en welke schermen traag laden. Dat kan met privacyvriendelijke middelen die zonder toestemmingsbanner werken omdat er geen persoonlijke profielen worden opgebouwd. Wat je daarmee wint is richting: je weet welk scherm aandacht nodig heeft in plaats van te gokken.

Verder hoort er foutmelding op afstand bij: als de app bij iemand vastloopt, komt er automatisch een melding binnen met de plek in de code, het toesteltype en de versie. In de praktijk lost dat de helft van de klachten op voordat iemand belt. Datzelfde geldt voor prestatiemeting — een scherm dat op een nieuw toestel in een halve seconde laadt, kan op een vier jaar oude telefoon vijf seconden kosten, en dat merk je alleen als je het meet.

Tot slot het versiebeleid. Afhankelijk van de gekozen opzet kunnen kleine verbeteringen rechtstreeks worden uitgerold zonder nieuwe beoordeling; grotere wijzigingen gaan opnieuw langs de store. Die momenten worden liever vooraf ingepland dan achteraf onder tijdsdruk. En bij elke versie hoort een korte notitie voor gebruikers wat er veranderd is — dat leest bijna niemand, maar het scheelt wel klachten van de mensen die het wél lezen.

Plaincodelab bouwt driedimensionaal werk — deze site is er zelf een voorbeeld van — maar houdt daar één regel bij aan: 3D moet iets uitleggen wat plat beeld niet kan. Een keukenblad dat je in je eigen keuken projecteert voordat je bestelt, een machine die je van alle kanten kunt bekijken met de onderdelen erbij, een pand dat je virtueel doorloopt: dat zijn gevallen waarin een gebruiker sneller begrijpt en zekerder beslist. Een draaiende bol op het beginscherm is dat niet.

In apps is een productconfigurator de meest voorkomende zinvolle toepassing. Kleur, maat, uitvoering en accessoires direct zichtbaar op het product zelf, met de prijs die meebeweegt. Dat verlaagt twijfel en daarmee retouren, en het scheelt gesprekken waarin iemand probeert uit te leggen hoe het eruit gaat zien. Voor bedrijven met veel varianten is dat vaak het onderdeel dat zichzelf het snelst terugverdient.

Augmented reality — een virtueel object in de echte ruimte — werkt goed voor alles wat groot, duur of moeilijk voor te stellen is. Meubels, zonwering, installaties, borden en belettering. Zowel iOS als Android hebben daar tegenwoordig een fatsoenlijke basis voor, waardoor je geen speciaal toestel meer nodig hebt. Wel geldt: hoe zwaarder de weergave, hoe zwaarder de accu, dus PCL bouwt altijd een eenvoudige weergave als terugvaloptie.

Op het web gebeurt dat met de 3D-mogelijkheden die de browser zelf biedt, in apps met de laag die het platform daarvoor heeft — of met een engine wanneer het echt spelachtig wordt. Modellen worden geoptimaliseerd voordat ze in de app komen: minder vlakken, samengevoegde texturen, en niveaus van detail zodat een telefoon niet hetzelfde hoeft te tekenen als een werkstation. Zonder die stap ziet 3D er prachtig uit op de laptop van de ontwerper en loopt het vast op het toestel van de klant.

En dan de terugvaloptie, die net zo belangrijk is als het effect zelf: elk 3D-onderdeel krijgt een variant zonder 3D. Voor oude toestellen, voor mensen die beweging hebben uitgezet in hun instellingen, en voor de momenten dat er iets misgaat. De inhoud moet altijd bereikbaar blijven; het beeld is een toevoeging, geen voorwaarde.

Het woord app dekt te veel lading, dus hieronder staan de soorten die in de praktijk het vaakst langskomen. Ze verschillen sterk in omvang, maar de vraag erachter is steeds dezelfde: iets wat nu op papier, in de mail of in een spreadsheet gebeurt, moet sneller en betrouwbaarder.

Buitendienst-apps zijn de klassieker. Monteurs, installateurs, hoveniers en schoonmakers krijgen hun planning binnen, vullen ter plekke een werkbon in met foto's en handtekening, en dat komt automatisch bij de administratie terecht. Offline werken is hier bijna altijd een eis, want kelders en dakconstructies hebben zelden bereik.

Klant- en ledenapps draaien om herhaling: inchecken bij een sportschool of club, een afspraak maken en verzetten, een strippenkaart of tegoed bijhouden, meldingen bij nieuwe roosters. De winst zit in het verminderen van telefoontjes en no-shows.

Bestel- en voorraadapps koppelen de vloer aan het systeem: scannen bij binnenkomst, bestellingen opnemen bij de klant, tellingen doen zonder papier. Hier verdient de app zich terug in fouten die niet meer gemaakt worden.

Verder bouwt PCL interne bedrijfsapps die processen vervangen waar geen standaardpakket voor bestaat, portalen waarin klanten hun eigen dossier, voortgang en documenten zien, en publieksapps rond een dienst of product — met accounts, betalingen en meldingen. En regelmatig komt daar de eerlijkste variant uit: geen app, maar een webapplicatie die hetzelfde doet voor een fractie van het budget.

In de meeste bedrijven bestaan de website en de app als twee losse werelden, gebouwd door twee partijen, met twee keer dezelfde gegevens die net niet gelijk lopen. Dat is duurder dan het moet zijn en het is de reden dat een klant in de app iets anders ziet dan op de site. Plaincodelab bouwt daarom liever één systeem met twee gezichten: dezelfde gegevens, dezelfde regels, dezelfde beheeromgeving, en daarbovenop een website voor wie zoekt en een app voor wie terugkomt.

Praktisch betekent dat één plek waar producten, prijzen, teksten, openingstijden en beschikbaarheid worden bijgehouden. Verandert er iets, dan verandert het overal tegelijk. Dat scheelt niet alleen fouten maar ook de vermoeiende discussie over wie welke lijst bijhoudt. Voor een winkel met voorraad, een club met roosters of een dienstverlener met agenda's is dat vrijwel altijd de doorslaggevende reden om het samen te ontwerpen.

Ook de rolverdeling wordt dan logisch. De website is er om gevonden te worden: die staat in Google, laadt snel, legt uit wat je doet en zet bezoekers aan tot contact of aankoop. De app is er voor wie je al kent: sneller inloggen, meldingen, opgeslagen voorkeuren, offline toegang. Wie die twee door elkaar haalt, bouwt een app die niemand vindt en een website die te traag is omdat hij te veel wil.

Er is een tussenvorm die vaak over het hoofd wordt gezien en die veel geld bespaart: de website zo bouwen dat hij als app te installeren is. Bezoekers die vaak terugkomen zetten hem op hun beginscherm, krijgen meldingen en werken offline verder, terwijl je maar één ding onderhoudt. Pas als er echt iets nodig is wat de browser niet kan, wordt het een store-app. Dat is niet de goedkope oplossing; het is meestal gewoon de juiste.

Bijna elk app-project dat uit de hand loopt, doet dat om dezelfde redenen. Ze staan hieronder, niet om iemand af te schrikken maar omdat ze goed te vermijden zijn als je ze vooraf kent.

De grootste is beginnen met alles. Een eerste versie met dertig functies kost veel en levert pas laat informatie op over wat mensen werkelijk gebruiken. Bijna altijd blijkt achteraf dat een derde van die functies nooit is aangeraakt. Begin met de handeling die het vaakst gebeurt en bouw de rest op basis van wat je dan ziet.

De tweede is niet nadenken over wie de gegevens bezit. Wie beheert de ontwikkelaarsaccounts, waar staat de code, wie heeft de sleutels, en wat gebeurt er als de samenwerking eindigt? Als het antwoord daarop 'het bureau' is, zit je vast. Accounts horen op naam van de opdrachtgever te staan en de code hoort met documentatie opgeleverd te worden, zodat overstappen mogelijk blijft. Dat is geen bijzondere gunst maar hoe het hoort.

De derde is het overslaan van de moeilijke schermen. Foutmeldingen, lege lijsten, verlopen sessies, mislukte betalingen, verbroken verbindingen. In demo's ziet niemand ze, in het echte gebruik zijn ze de helft van de ervaring. Ze later toevoegen kost meer dan ze meteen ontwerpen.

De vierde is een app maken zonder plan om er gebruikers in te krijgen. Een app in de store is niet vindbaar zoals een website in Google; mensen moeten weten dat hij bestaat. Zonder een eenvoudig plan — een pagina op je site, een QR-code op de balie, een mail naar bestaande klanten, een reden om hem te openen — blijft het bij tientallen downloads.

En de vijfde is onderhoud niet begroten. De bouw is een investering, het draaien is een abonnement. Wie alleen de eerste post begroot, staat over een jaar voor de keuze om alsnog te betalen of te stoppen.

Een app is geen winkel op een druk plein maar een pand in een straat die niemand toevallig inloopt. Downloads komen bij het midden- en kleinbedrijf zelden uit de store zelf; ze komen van je eigen kanalen. Daarom hoort de lancering al in het ontwerp thuis, niet als losse actie achteraf.

Het vertrekpunt is een pagina op je eigen website die uitlegt wat de app doet, met knoppen naar beide stores en een QR-code die op de telefoon meteen de juiste winkel opent. Daarnaast: een bericht aan bestaande klanten, een QR-code op de balie, op de factuur of op het bestelbonnetje, en de mensen aan de balie die er in één zin iets over kunnen zeggen. Dat laatste doet in de praktijk meer dan alle advertenties bij elkaar.

In de store zelf gelden andere regels. De naam en de ondertitel wegen zwaar in het zoeken, de eerste schermafbeelding bepaalt of iemand doorklikt, en beoordelingen bepalen of hij installeert. Vraag daarom op een goed moment om een beoordeling — niet bij het eerste openen, maar nadat iemand iets met succes heeft afgerond — en reageer op recensies, ook op de kritische. Dat wordt gelezen.

Het echte werk begint bij de eerste keer openen. Wie meteen een registratieformulier van tien velden ziet, is weg. Laat de app eerst iets nuttigs doen, vraag alleen wat je nu nodig hebt, en leg toestemmingen uit op het moment dat ze aan de beurt zijn. Dat eerste gebruik bepaalt of iemand terugkomt.

Meldingen zijn daarna je sterkste middel en tegelijk de snelste manier om verwijderd te worden. De regel: alleen sturen wat voor die ene persoon op dat moment relevant is — je afspraak is morgen, je bestelling is onderweg, je rooster is gewijzigd. Geen algemene nieuwsbrieven per melding. Laat mensen per soort melding kiezen wat ze willen ontvangen, en houd bij hoeveel mensen na een melding daadwerkelijk de app openen. Zakt dat, dan stuur je te veel of het verkeerde.

Een app is bedrijfseigendom, geen abonnement bij het bureau dat hem toevallig bouwde. Toch komt Plaincodelab regelmatig situaties tegen waarin een ondernemer niet bij zijn eigen ontwikkelaarsaccount kan, de code nergens ziet staan en niet weet welke externe diensten er onder de app hangen. Dan is overstappen niet duur maar onmogelijk, en dat weet de leverancier ook.

De afspraak hoort simpel te zijn. De ontwikkelaarsaccounts bij Apple en Google staan op naam van je bedrijf. De code staat in een archief waar jij toegang toe hebt en dat je mag meenemen. De sleutels en certificaten waarmee de app ondertekend wordt, zijn van jou en worden veilig bewaard, want wie die kwijtraakt kan geen nieuwe versie meer uitbrengen onder dezelfde app. Domeinen, hosting en externe diensten staan eveneens op naam van je eigen bedrijf, ook als iemand anders het dagelijkse werk doet.

Bij oplevering hoort documentatie: hoe zet je een ontwikkelomgeving op, hoe wordt een nieuwe versie gebouwd en uitgebracht, welke externe diensten worden gebruikt en waarvoor, waar staan de gegevens en hoe ziet de gegevensstructuur eruit. Niet honderd pagina's, wel genoeg dat een andere ontwikkelaar er zonder overdrachtsgesprek mee verder kan. Dat is de eerlijkste test van goede oplevering: kan iemand anders het overnemen zonder jou te bellen.

Datzelfde geldt voor het einde van een samenwerking. Er hoort geen drempel te zijn die je vasthoudt behalve tevredenheid. In de praktijk blijkt dat ook de prettigste manier van werken: als een klant elk moment kan vertrekken, blijft de aandacht waar hij hoort — bij het werk.

Offertes voor apps staan vol woorden die voor de bouwer vanzelfsprekend zijn en voor de opdrachtgever niet. Dat is vervelend, want juist die woorden bepalen wat je krijgt en wat je later kunt. Hieronder staan de termen die het vaakst langskomen, in gewone taal, zodat je twee offertes naast elkaar kunt leggen en ziet waar ze werkelijk van elkaar verschillen.

Een tip vooraf: vraag bij elk begrip dat je niet kent wat het concreet betekent voor jouw project, en niet wat het in het algemeen betekent. Een leverancier die dat niet in twee zinnen kan uitleggen, gaat het gedurende het project ook niet uitleggen. Plaincodelab schrijft offertes daarom in gewone taal, met de vaktermen erachter tussen haakjes in plaats van andersom.