AI Hiring

App laten maken: wat het kost en op wiens naam hij komt te staan

Een app laten maken: wat de prijs bepaalt, welke kosten elk jaar terugkomen, wat de appwinkels eisen, en op wiens naam het ontwikkelaarsaccount hoort te staan.

aiworktalent Redactie · 5 september 2026 · 28 min leestijd

Een app laten maken begint bijna altijd met dezelfde vraag: wat kost dat? Het eerlijke antwoord is dat wij geen onafhankelijke Nederlandse partij hebben gevonden die publiceert wat een app gemiddeld kost. De app-totaalbedragen die je online tegenkomt, komen vrijwel allemaal van partijen die apps bouwen of verkopen. Wat je wel kunt onderbouwen, zijn de uurtarieven uit onderzoek onder zzp'ers, de vaste kosten van de twee appwinkels en de verplichtingen die daarna elk jaar terugkomen.

Deze post gaat over het uitbesteden zelf: wat de prijs bepaalt, wat je in je aanvraag moet zetten, wat de winkels weigeren, en op wiens naam je app straks staat. Dat laatste behandelt vrijwel geen enkele Nederlandse pagina over app-kosten, terwijl het bij een app zwaarder weegt dan bij een website. Een domeinnaam kun je verhuizen. Een ontwikkelaarsaccount en een ondertekeningssleutel niet zomaar.

We bouwen zelf geen apps en verkopen hier geen bouwuren. Dat is precies waarom deze post ook de gevallen noemt waarin je beter geen app laat maken, en waarin een bureau de betere keuze is dan een zelfstandige.

Wat je koopt als je een app laat maken

Je koopt geen bestand dat af is. Je koopt drie dingen die los van elkaar geregeld moeten worden: de code, een plek in twee winkels die je niet bezit, en de verplichting om die plek bij te houden. De meeste problemen achteraf komen doordat alleen het eerste in de offerte stond.

Begin daarom bij de vraag of je wel een app nodig hebt. Een goede mobiele website doet vaak hetzelfde, en die heeft geen winkelbeoordeling, geen jaarlijkse technische ronde en geen ontwikkelaarsaccount nodig. Meldingen, offline doorwerken en de camera kan een webapp ook. Een app verdient zichzelf pas terug als je toegang tot het toestel nodig hebt die de browser niet geeft, of bij dagelijks gebruik door dezelfde mensen.

Dat laatste is het echte onderscheid. Een app voor klanten die twee keer per jaar iets bestellen, wordt zelden geopend. Een app voor je monteurs die elke dag bonnen invullen, verdient zich wel terug. Hoe zo'n dagelijkse toepassing eruitziet, staat uitgewerkt in het artikel over de werkbon app en de digitale werkbon.

Let ook op wat er onder de app hangt. Bijna elke zakelijke app praat met iets: je planning, je voorraad, je boekhouding. Dat deel is vaak groter dan de app zelf, en meestal ook het deel dat het langst duurt. Vraag dus niet alleen wat de app kost, maar ook wat de koppeling kost en wie de fout oplost als een van beide kanten verandert.

Wat bepaalt de prijs van een app?

Een app is geen product met een prijskaartje, maar een aantal uren werk. Daarom lopen de bedragen die je online tegenkomt zo uiteen: van een kant-en-klare app uit een abonnement van een paar tientjes per maand tot maatwerk van tienduizenden euro's. Dat komt niet doordat iemand liegt, maar doordat het woord "app" drie verschillende dingen kan betekenen: zo'n abonnementsapp, een app die je op maat laat bouwen, en een website die zich als app gedraagt. De rest van dit hoofdstuk gaat over de tweede.

Wat wel meetbaar is, is het uurtarief. Voor het Zzp Uurtarievenboekje 2026 vroeg Knab ruim 20.000 zelfstandigen naar hun tarief. Een zelfstandig software developer rekent daarin gemiddeld 94 euro per uur exclusief btw, bij gemiddeld 33 declarabele uren per week. Over alle beroepen heen komt het gemiddelde uit op 83 euro, tegen 81 euro het jaar ervoor. Voor de specialisatie mobile development noemt Knab gemiddeld 95 euro per uur exclusief btw, vrijwel gelijk aan de 94 euro voor software developers in het algemeen. Dat cijfer staat niet op de site zelf: je vindt het in de tarieflijst achter in het boekje, dat je met je e-mailadres aanvraagt.

Aan de bovenkant van de markt ligt het hoger. Volgens de Talent Monitor van HeadFirst Group en Intelligence Group kwam het gemiddelde uurtarief van ict-professionals in 2025 voor het eerst boven de 100 euro uit. Dat cijfer gaat wel over bemiddelde inhuur bij grote organisaties, niet over een mkb'er die één app laat bouwen. Het is dus een plafond, geen richtprijs.

Het CBS meet alleen de prijsontwikkeling van softwareconsultancy, elk kwartaal bij een vast panel van 82 bedrijven. Dat is een prijsindex: die laat zien of tarieven stijgen of dalen, niet wat iets kost. De cijfers zelf staan in de tabel dienstenprijzen, onder computerprogrammering en advisering. Op vergelijkingssites kom je bedragen tegen als 90 euro per uur voor een app-ontwikkelaar, maar zulke sites zeggen er zelf bij dat het om een indicatie gaat, samengesteld uit openbare informatie van internet.

Knab meet ook projectprijzen. Van de zelfstandige software developers werkt 22 procent daar onder andere mee, en het meest voorkomende bedrag ligt tussen 5.000 en 10.000 euro exclusief btw. Dat gaat over softwareprojecten in het algemeen, niet over apps, en het is zelfrapportage. Als eerste ijkpunt is het bruikbaar, als prijs voor jouw app niet.

De praktische conclusie: vraag geen prijs, vraag een urenraming per onderdeel. Dus niet "wat kost mijn app", maar hoeveel uur er gaat zitten in het ontwerp, de app zelf, de achterliggende systemen, de koppelingen, het testen en het publiceren. Pas dan kun je twee offertes naast elkaar leggen. Een bedrag zonder uren vergelijkt niets: de goedkoopste offerte is vaak gewoon de kleinste opdracht.

Reken daarbij op twee dingen die vrijwel altijd worden vergeten. Twee besturingssystemen betekenen twee keer testen, ook als er maar één keer gebouwd wordt. En de app is niet af als hij werkt, maar als hij door de beoordeling van de winkel heen is.

Native, hybride of eigenlijk een webapp?

Er zijn grofweg drie manieren om het te bouwen, en het verschil in prijs zit vooral in hoe vaak het werk dubbel gedaan moet worden.

Over de middelste optie lees je vaak dat die zoveel procent goedkoper is. Er is geen onafhankelijk onderzoek dat zo'n getal onderbouwt; het komt uit marketingmateriaal. Wat wel vaststaat, is dat beide technieken springlevend zijn. React Native is sinds februari 2026 ondergebracht bij een onafhankelijke stichting, en er verschijnt ongeveer elke twee maanden een nieuwe versie. Van Flutter verscheen in augustus 2026 nog een nieuwe versie, en Google schrijft in de eigen routekaart dat er inmiddels meer mensen van buiten Google aan meewerken dan Google-medewerkers. Google noemt die routekaart nadrukkelijk een intentie en geen garantie.

Vraag je bouwer daarom niet wat het populairst is, maar twee andere dingen: waarom kiest hij dit voor jouw app, en wie kan het overnemen als hij ermee stopt. Dat tweede antwoord telt bij een app zwaarder dan bij een website, omdat je niet zomaar van bouwer kunt wisselen zonder ook het account en de sleutels mee te nemen.

Kan het niet gewoon met AI?

Hier lopen twee verschillende vragen door elkaar, en ze hebben niet hetzelfde antwoord. De eerste is of je bouwer AI-gereedschap gebruikt. Dat doen veel bouwers inmiddels, het kan de bouwuren flink drukken, en je mag gerust vragen waarmee hij werkt. De tweede vraag is of je het daarmee zelf kunt.

Dat tweede kan een heel eind komen, maar de winkelregels veranderen niet mee. Apple weigert apps die niet meer zijn dan een ingepakte website, en vraagt letterlijk om functies en bediening die verder gaan dan een herverpakte site. Google stelt in het eigen beleid dat een app minstens een basisniveau aan functionaliteit en een fatsoenlijke ervaring moet bieden. Die twee regels gaan over wat de app doet, niet over waarmee hij gemaakt is. Op één punt kijkt Apple wel naar de herkomst: komt de app uit een kant-en-klaar sjabloon of een app-generator, dan mag alleen de partij van wie de inhoud is hem indienen. Dus jij, niet je leverancier namens jou.

Let daarnaast op wat een no-code app-bouwer precies levert, want dat verschilt sterk. Sommige aanbieders leveren een webapp die je klanten op hun beginscherm zetten en noemen de App Store en Google Play nergens. Andere zeggen op de eigen site echte apps te bouwen en die rechtstreeks bij beide winkels te kunnen indienen. Dat is wat de leverancier zelf zegt; onafhankelijk bewijs hoe vaak dat zonder afkeuring lukt, is er niet. Eén aanbieder verwijst zijn gebruikers in de eigen handleiding gewoon naar de regels van Apple en Google, inclusief de eis rond minimale functionaliteit.

Het gereedschap bepaalt dus vooral de snelheid. Wat het niet bepaalt, is of iemand de winkelregels kent, of de privacyvragen vooraf zijn beantwoord, en of er over een jaar nog iemand is die de app kan bijwerken. Dat is geen argument tegen die tools, en al helemaal niet tegen de bouwers die ermee werken. Het is een argument om te vragen wie de verantwoordelijkheid draagt als de app wordt afgekeurd.

De rekening die doorloopt: een app veroudert vanzelf

Dit is het grootste verschil met een website. Een website kun je een jaar met rust laten; hij blijft gewoon bereikbaar. Een app niet. Apple en Google verhogen elk jaar de technische eisen, en wie niets doet, valt er stapsgewijs uit.

Die laatste post is er voor veel zakelijke apps helemaal niet. Levert je app iets buiten de app om, denk aan bezorging, een afspraak, een reparatie of een kaartje, dan mag je de betaalknop van Apple en Google juist niet gebruiken. Dat schrijven beide winkels voor. Je regelt het betalen dan zelf, en er gaat geen commissie af. Google noemt daarnaast nog een paar uitzonderingen, waaronder onderling geld overmaken tussen gebruikers, veilingen, en giften aan een goed doel met belastingvrijstelling.

Verkoop je wel iets digitaals in de app, dan hangt het tarief af van de winkel en van de markt. Buiten de Europese Unie rekent Apple 30 procent. Dat wordt 15 procent voor deelnemers aan de regeling voor kleine aanbieders, en voor abonnementen na het eerste jaar. Die regeling scheelt echt geld, dus meld je aan. Je komt in aanmerking zolang je uitbetalingen onder een miljoen dollar blijven, en dat geldt voor vorig jaar en voor het lopende jaar. Uitbetalingen zijn wat overblijft ná Apples commissie en belastingen, dus niet je omzet. In de Europese Unie liggen de tarieven anders. Apple kondigde daar in augustus 2026 nieuwe voorwaarden aan, die ingaan op 1 oktober 2026. Wat je daar betaalt hangt af van hoe je verkoopt, dus noemen we hier geen percentage. Kijk het bedrag na op de EU-pagina van Apple als je gaat begroten. Google Play rekent sinds 30 juni 2026 een nieuw tarief bij verkoop aan gebruikers in de EER, het Verenigd Koninkrijk en de Verenigde Staten. Dat is 10 procent over de eerste miljoen dollar per jaar, plus 5 procent voor de betaalafhandeling. Dat lage tarief geldt voor abonnementen en voor verkopen aan wie de app net heeft geïnstalleerd. Koopt iemand die de app al langer heeft er iets bij, dan rekent Google 20 procent plus dezelfde 5 procent. Kom je boven die miljoendrempel, kijk het tarief dan na bij Google voordat je begroot. Buiten die drie gebieden geldt bij Google voorlopig nog de oude structuur: 15 procent tot een miljoen dollar en 30 procent daarboven. Kom je oude percentages tegen, kijk dan eerst om welke winkel en welke markt het gaat.

Over onderhoud circuleert de vuistregel dat je jaarlijks tien tot twintig procent van de bouwsom moet reserveren. Wij hebben geen onderzoek, brancheorganisatie of statistiekbureau kunnen vinden dat dat percentage onderbouwt. Zet daarom een kalender in je begroting in plaats van een percentage: er staat elk jaar minstens één verplichte ronde op de rol, en die moet iemand doen.

Doe je dat niet, dan ruimen de winkels uiteindelijk op. Is je app drie jaar niet bijgewerkt en wordt hij in twaalf maanden nauwelijks nog gedownload, dan stuurt Apple een bericht en heb je negentig dagen om een update in te leveren. Google kan een ontwikkelaarsaccount sluiten dat stilligt: is je account ouder dan een jaar en heb je nog nooit een app ter beoordeling ingediend, dan is dat al genoeg. Heb je wel apps, dan moet alles tegelijk spelen: ook ouder dan een jaar, samen minder dan duizend installaties, telefoonnummer en e-mailadres niet bevestigd, en een half jaar niet ingelogd. Google waarschuwt zestig, dertig en zeven dagen van tevoren per e-mail, maar de 25 dollar krijg je niet terug.

Op wiens naam staat je app?

Dit is het hoofdstuk dat vrijwel nergens staat, en het is het duurste om achteraf te repareren. Bij een app gaat eigendom niet over één ding, maar over vier losse dingen. Je moet ze stuk voor stuk apart regelen: het auteursrecht op de code, de broncode zelf, de twee winkelaccounts, en de ondertekeningssleutels.

Om te beginnen het auteursrecht. In Nederland ontstaat dat bij degene die het werk maakt, en betalen voor de bouw levert je dat recht niet automatisch op. De bekendste uitzondering waarbij de opdrachtgever meteen als maker geldt, is werk in loondienst. De wet kent nog twee routes, maar die zijn bij een uitbestede app te onzeker om op te bouwen. Huur je een zelfstandige of een bureau in, dan blijft het recht bij hen tenzij je het uitdrukkelijk overneemt. Artikel 2 lid 3 van de Auteurswet vraagt daarvoor een schriftelijke overeenkomst, en de overdracht zelf gebeurt bij een daartoe bestemde akte. Een ondertekend stuk dat uitdrukkelijk zegt dat het auteursrecht overgaat, voldoet daaraan; een notaris is niet nodig.

Twee dingen zijn bij software anders dan bij een tekst of een foto. Software heeft in de Auteurswet een eigen hoofdstuk, en daar valt niet alleen de code onder maar ook het voorbereidend materiaal: ontwerpen en specificaties. Noem die dus apart in je contract. Daarnaast geldt het auteurscontractenrecht niet voor software. Dat hoofdstuk beschermt de maker tegen de partij die zijn werk exploiteert, dus je bouwer kan zich daar bij een app niet op beroepen. Andersom werkt het net zo min: als opdrachtgever krijg je van de wet geen rechten op de code cadeau. Alles wat je in handen wilt hebben, moet je zelf op papier zetten.

Heb je de app rechtmatig gekregen, dan mag je hem gebruiken waarvoor hij bedoeld is. Maar dat geeft je geen recht op de broncode, en zonder broncode kun je er in de praktijk niets aan laten veranderen. De wettelijke uitzondering om software uit elkaar te halen is er om programma's op elkaar te laten aansluiten, niet om je app te kunnen onderhouden als je bouwer niet meewerkt. Reken daar dus niet op als noodplan. Zet afgifte van de broncode gewoon in het contract, als voorwaarde bij oplevering.

Dan de winkelaccounts, en hier zit het verschil met een website. Bij Apple kan alleen de accounthouder een app-overdracht starten; jij accepteert die daarna. Er is geen knop waarmee jij je eigen app ophaalt als je bouwer niet meewerkt. Apple stelt bovendien voorwaarden: de app moet al minstens één keer in de App Store zijn verschenen. Hij mag ook niet in pre-order staan, in beoordeling zijn of op publicatie wachten. Zo'n overdracht verhuist de plek in de winkel, maar geen broncode: Apple schrijft zelf dat de overdragende partij de code en de bouwbestanden rechtstreeks aan jou moet geven.

De rol van accounthouder overnemen is geen alternatief. Apple staat het doorgeven daarvan alleen toe aan iemand die al in hetzelfde team zit. Bij Google Play kan dat wel: daar is naast een app-overdracht ook het hele ontwikkelaarsaccount overdraagbaar, met identiteitscontrole en een wachttijd van zeven dagen. Voor een app-overdracht vraagt Google de transactie-ID van de registratiebetaling van beide accounts, dus het betaalbewijs van de eenmalige 25 dollar. Die van het oude account kan alleen je bouwer opzoeken; ook daar is medewerking dus vereist. Je hebt verder het e-mailadres van de eigenaar van het nieuwe account nodig, en beide accounts moeten geregistreerd en actief zijn. Kost je app geld of verkoop je er iets in, dan hoort daar ook een actief betalingsprofiel bij. Koppelingen met diensten als Firebase, Analytics en advertentienetwerken gaan niet mee. Koppel ze vooraf los en richt ze daarna in het nieuwe account opnieuw in.

Blijft over het onderdeel dat het minst bekend is: de sleutels. Een Android-update wordt alleen geaccepteerd als hij met hetzelfde certificaat is ondertekend als de vorige versie, en een eenmaal gemaakte sleutel kun je niet opnieuw aanmaken. Toch is een zoekgeraakte sleutel bij een nieuwe app geen ramp meer. Nieuwe apps in Google Play moeten sinds augustus 2021 de ondertekeningsdienst van Google gebruiken. Google bewaart dan de eigenlijke sleutel, en je bouwer werkt met een aparte uploadsleutel die Google op verzoek kan resetten.

Er blijft genoeg over om vast te leggen. Laat schriftelijk bevestigen wie de uploadsleutel beheert en dat je die bij oplevering krijgt. Neem je een bestaande app over die van vóór augustus 2021 is en nooit is overgestapt, dan ligt de enige sleutel nog bij je bouwer. Datzelfde geldt voor een Android-app die je buiten de winkel om verspreidt. Raakt zo'n sleutel kwijt, dan moet de app als nieuwe app in de winkel, onder een andere technische naam, met je downloads en beoordelingen weer op nul. Bij Apple bestaat zo'n dienst niet: de sleutels die je aanmaakt voor pushberichten of voor inloggen met Apple kun je maar één keer downloaden, en Apple bewaart ze niet.

Let ten slotte op de technische naam van je Android-app. Die ligt vast zodra je bouwer de app naar Google Play uploadt: wijzigen kan daarna niet meer, alleen de hele app weggooien en opnieuw beginnen. En dat helpt zelden. Alleen bij een verwijderde app die nooit is geïnstalleerd geeft Google de naam weer vrij; is hij ook maar één keer geïnstalleerd, dan is de naam voorgoed vergeven, ook aan jou. Verwijderen kan bovendien alleen de accounthouder, en dat is hier juist je bouwer. Laat hem daar dus niet zijn eigen bedrijfsnaam in zetten, en controleer de naam vóór die eerste upload. Zet in je contract een lijst van wat je bij oplevering in handen wilt hebben:

• Het ontwikkelaarsaccount bij Apple en bij Google op naam van je eigen bedrijf. Niet op naam van je bouwer, ook niet "voorlopig even".
• De ondertekeningssleutels, of de bevestiging dat de ondertekeningsdienst van Google aanstaat. Vraag om een schriftelijke bevestiging waar de sleutels liggen.
• De broncode én het voorbereidend materiaal. Dus ook de ontwerpbestanden en de specificaties, in een omgeving waar jij bij kunt.
• De overdracht van het auteursrecht op papier. Ondertekend, met de code en het voorbereidend materiaal er met zoveel woorden in genoemd.
• De toegang tot de achterliggende systemen. Hosting, database en de accounts van elke dienst waar de app mee praat.
• De technische naam van de app. Controleer die vóór de eerste upload naar Google Play, want daarna ligt hij vast.

Escrow, waarbij een onafhankelijke partij de broncode bewaart en pas vrijgeeft als er iets vooraf afgesproken gebeurt, is hier zelden het antwoord. Die constructie is bedacht voor software die je alleen in licentie hebt. Laat je een app op maat bouwen, dan is het meestal eenvoudiger om vanaf dag één zelf eigenaar te zijn. Wat escrow kost, is bovendien lastig vooraf te zeggen: aanbieders publiceren doorgaans geen tarieven.

Wat de winkels weigeren, en wat dat met je planning doet

Een app is niet af als hij werkt. Hij is af als hij door de beoordeling heen is, en dat is geen formaliteit. Apple beoordeelde in 2025 ruim 9,1 miljoen inzendingen en wees er meer dan 2 miljoen af, waarvan ruim 443.000 om privacyredenen. Let op wat daar staat: het gaat om inzendingen, niet om apps. Eén app die twee keer wordt afgekeurd, telt twee keer mee. Het zegt dus niets over jouw kans, maar wel iets over hoe vaak er iets terugkomt.

Een paar redenen kun je vooraf uitsluiten. De bekendste is de app die feitelijk je website in een schilletje is; die komt er niet in. De tweede is minder bekend en juist voor uitbesteden belangrijk. In de beoordelingsrichtlijnen van Apple staat een aparte regel voor apps die uit een gecommercialiseerd sjabloon of een app-generator komen: die mogen alleen worden ingediend door de partij van wie de inhoud is. Dus door jou, niet door je leverancier namens jou. Dat is meteen het sterkste praktische argument om het account op je eigen naam te zetten. Er is nog een reden om dat te doen. Voor apps die een bedrijf in de Europese Unie uitbrengt, tonen de winkels wie erachter zit. Staat het account op naam van je bouwer, dan komen zijn adres, telefoonnummer en e-mailadres openbaar op de pagina van jouw app.

Reken ook op wachttijd die niets met bouwen te maken heeft. Wil je de app op naam van je bedrijf zetten, dan willen beide winkels een ingeschreven rechtspersoon zien met een D-U-N-S-nummer, en het aanvragen daarvan kan tot dertig dagen duren. Apple vraagt daarnaast een e-mailadres op je eigen domein en een werkende website op datzelfde domein. Bij Google hoeven alleen je officiële bedrijfsnaam en adres overeen te komen met je profiel bij Dun & Bradstreet; je e-mailadres en telefoonnummer bevestig je met een eenmalige code.

Heb je bij Google Play een persoonlijk account dat na 13 november 2023 is aangemaakt, dan komt daar nog een eis bij. Je moet eerst een besloten test doen met minstens twaalf testers die veertien dagen aaneengesloten meedoen, vóórdat je mag publiceren. Google beschrijft die eis uitdrukkelijk voor persoonlijke accounts. Of een zakelijk account daarvan is vrijgesteld, staat niet met zoveel woorden op de pagina van Google zelf. Ga daar dus niet blind van uit, en reken die weken mee in je planning.

Twee technische eisen leveren in de praktijk verrassingen op. Meldingen zijn geen knop die je aanzet: sinds Android 13 moet de gebruiker er apart toestemming voor geven, en weigert hij, dan komt er niets meer door. Vraagt de app het op het verkeerde moment, dan ben je die toestemming kwijt. Wil je app de locatie ook op de achtergrond gebruiken, dan is dat bij Google een aparte goedkeuring. Daar hoort een formulier bij, een korte video waarin je de functie laat zien, en uitleg in de app voordat je het vraagt.

Laat inloggen tot slot niet als restpunt staan. Apple eist dat gebruikers hun account ook in de app zelf kunnen verwijderen. Laat je mensen inloggen via een dienst van een ander, dan wil Apple daarnaast een inlogoptie die het e-mailadres van je klant kan afschermen. Inloggen met Apple voldoet daaraan. Zet die punten in je offerteaanvraag, want ze achteraf inbouwen is duurder dan ze vooraf meenemen.

Wat de wet van jou vraagt, niet van je bouwer

Bij vrijwel alles hieronder ligt de verantwoordelijkheid bij de partij die de app uitbrengt. Dat ben jij, ook als iemand anders hem heeft gebouwd. Wil je een deel van dat risico bij je bouwer leggen, dan moet dat in het contract staan; het gebeurt niet vanzelf.

Om te beginnen toegankelijkheid. Sinds 28 juni 2025 gelden daarvoor wettelijke eisen, en die gelden voor een app net zo goed als voor een website: de Europese regel noemt met zoveel woorden diensten op basis van mobiele apparatuur. Het gaat alleen om verkoop aan consumenten. Heb je minder dan tien mensen in dienst én een jaaromzet of balanstotaal van hoogstens twee miljoen euro, dan val je als micro-onderneming buiten de plicht. De Autoriteit Consument en Markt noemt op haar eigen pagina alleen de omzetgrens, dus houd bij twijfel de strengste lezing aan. Let op de twee randen: het personeelsaantal en de financiële grens moeten allebei gelden, en vanaf tien werknemers geldt de plicht gewoon.

Val je er wel onder, dan zijn er drie dingen die ondernemers verrassen. Een gratis app telt mee als klanten met hun persoonsgegevens betalen. Je moet een toegankelijkheidsverklaring publiceren, en die moet zelf ook toegankelijk zijn. En "ik heb er geen tijd voor" of "ik weet er te weinig van" telt volgens de ACM niet als reden. Kosten wel: zijn die onredelijk hoog tegenover de voordelen voor mensen met een beperking, dan heet dat een onevenredige last. Dan hoef je alleen die onderdelen niet aan te passen; de rest moet nog steeds toegankelijk zijn. Je moet die afweging wel onderbouwen, vastleggen in een document en bij de ACM melden. De ACM noemt WCAG 2.1 op niveau AA als de lat, en schrijft dat versie 2.2 op niveau AA in de loop van 2026 de standaard wordt.

Meteen een besparing erbij: krijg je een offerte waarin een dure toegankelijkheidsaudit als wettelijke eis staat, dan klopt dat niet. De ACM zegt zelf dat een onafhankelijke keuring, een certificaat of een keurmerk niet verplicht is. Zet in je aanvraag dat de oplevering aan WCAG 2.1 niveau AA moet voldoen, en meteen aan 2.2 als je niet volgend jaar opnieuw wilt bijwerken. Vraag hoe dat wordt aangetoond; dat telt, niet een certificaat.

Dan toestemming. Veel ondernemers denken dat de cookieregels alleen over websites gaan, maar de wet spreekt niet over cookies: hij gaat over het opslaan van of toegang krijgen tot informatie op het apparaat van je klant. Dat gebeurt in een app net zo goed. De Europese privacytoezichthouders hebben in richtsnoeren uit 2024 uitgelegd dat ook standaard ingebouwde pakketten van derden en unieke apparaatnummers eronder vallen. Er zijn maar weinig uitzonderingen: wat strikt nodig is om de app te laten werken, plus eenvoudige metingen die nauwelijks iets over de gebruiker prijsgeven. Alles wat met advertenties of profielen te maken heeft, valt daarbuiten.

De privacywet vraagt bovendien dat je die keuzes al bij het ontwerp maakt, niet pas bij de oplevering. Zet daarom drie vragen in je offerteaanvraag: welke toegang vraagt de app precies, welke pakketten van anderen zitten erin, en op welk moment wordt om toestemming gevraagd. Een verwerkersovereenkomst met je bouwer is verplicht, niet optioneel: artikel 28 van de AVG eist die. Vraag daarbij om een lijst van alle partijen die hij inschakelt; hij mag daar niet zomaar anderen aan toevoegen. En het verwerkingsregister waarvan iedereen denkt dat het pas vanaf 250 medewerkers hoeft: die uitzondering vervalt zodra je niet af en toe maar dagelijks persoonsgegevens verwerkt, en dat doet elke app met klantaccounts.

Verder moet je zichtbaar zijn. Breng je vanuit je bedrijf een app uit in de Europese Unie, dan controleren de winkels wie erachter zit en tonen ze die gegevens. Ook bij een gratis app: het gaat erom dat je handelt vanuit je beroep of bedrijf, niet om wat de app kost. Bouw je puur als hobby, zonder plan om er iets mee te verdienen, dan geldt het niet voor jou. Je bedrijfsnaam, adres, telefoonnummer en e-mailadres komen op de pagina van je app te staan, je KvK-nummer niet. Apple neemt dat serieus en haalt sinds 17 februari 2025 apps zonder geverifieerde handelaarsstatus uit de Europese App Store, totdat die status is opgegeven en gecontroleerd. Werk je als eenmanszaak vanuit huis, dan mag je bij Apple een postbus opgeven, met een bewijsstuk dat dat adres van jou is. Bij Google Play hangt het aan je accounttype: bij een zakelijk account staat je volledige adres er altijd bij, bij een persoonlijk account pas zodra je met de app geld verdient. Google haalt dat adres uit je betalingsprofiel, dus zet dat op je bedrijfsadres voordat je publiceert.

Nog één datum om nu al in te plannen. De Europese verordening cyberweerbaarheid geldt al, en de hoofdregel is dat wie de app onder zijn eigen naam uitbrengt als fabrikant geldt. Dat woord staat los van de maker uit het auteursrecht hierboven: het gaat hier om wie verantwoordelijk is voor de veiligheid. Vanaf 11 september 2026 moet je een beveiligingslek dat actief wordt misbruikt binnen 24 uur melden bij de autoriteiten. Dat kun je alleen als iemand je app in de gaten houdt. Spreek dus vóór de bouw af wie dat doet en hoe je diegene buiten kantooruren bereikt.

Eén regel geldt waarschijnlijk niet voor jou: de Europese wet voor onlineplatforms is niet geschreven voor een app die alleen je eigen aanbod toont. Laten gebruikers in de app zelf dingen achter die anderen zien, zoals beoordelingen of berichten, dan verandert dat beeld en is het verstandig het na te laten kijken.

Bureau of zelfstandige: wat past bij jouw opdracht?

Bij een app is deze keuze scherper dan bij een website, omdat er meer losse onderdelen zijn: de app zelf, de achterliggende systemen, twee winkels en een beoordeling die kan misgaan. Eén persoon die dat allemaal doet, bestaat wel, maar is zeldzaam.

Er is nog een derde weg die vaak beter werkt dan allebei: begin kleiner. Laat eerst het onderdeel bouwen waar je dagelijks last van hebt, en kijk of het gebruikt wordt voordat je de rest laat maken. Welke taak zich daarvoor leent, staat uitgewerkt in het artikel over uitbesteden of zelf doen, en de rollen die je daarbij tegenkomt staan in wat een AI automation engineer doet.

En soms is het eerlijke antwoord dat je helemaal geen app nodig hebt, maar software die je werk regelt. Wie in de installatie- of bouwsector zit, herkent dat waarschijnlijk in het overzicht over software voor installateurs. Twijfel je nog tussen een app, een webapp of een aanpassing aan je huidige systeem? Dan helpt het stappenplan voor AI in het mkb om die vraag eerst scherp te krijgen.

Een app laten maken wordt zelden duur door het uurtarief. Het wordt duur door wat er niet is afgesproken: wie de sleutels heeft, op wiens naam het account staat, en wie er volgend jaar de verplichte ronde doet. Vraag om een urenraming per onderdeel, zet de opleverlijst uit dit artikel in je contract, en regel het ontwikkelaarsaccount vóórdat de bouw begint. Weet je niet of je een zelfstandige of een team nodig hebt? Plaats je opdracht op aiworktalent en ontvang voorstellen van specialisten, zodat je de aanpakken naast elkaar kunt leggen voordat je kiest.