Geld verdienen met een app: verdienmodellen uitgelegd

Apps verdienen geld op een handvol manieren: een abonnement, een eenmalige prijs, een vergoeding voor gebruik, een deel van de transacties tussen gebruikers, advertenties, of diensten rond de app verkopen. Het juiste model hangt af van hoe vaak mensen hem gebruiken en hoeveel waarde elk gebruik oplevert. Een tool waar mensen elke week op vertrouwen past bij een abonnement; een eenmalig hulpprogramma past bij één betaling. Ook hoe je de app verspreidt is van belang: een webapp neemt betalingen aan via een verwerker zoals Stripe, terwijl native apps die via de App Store of Google Play worden verkocht aan de regels en commissies van die stores gebonden zijn.

De belangrijkste verdienmodellen

Abonnementen

Het meest voorkomende model voor softwarebedrijven, omdat de omzet zich herhaalt en groeit naarmate je klanten toevoegt. Het werkt wanneer de app deel uitmaakt van iemands vaste routine. Bied maandelijkse en jaarlijkse opties aan; jaarplannen komen meestal met korting in ruil voor een verplichting. De prijsstructuur (niveaus, per gebruiker, vaste prijs) is een onderwerp op zich; zie hoe je een SaaS-product prijst.

Eenmalige betalingen

Eenvoudig uit te leggen en makkelijk te kopen. Het addertje: als de app doorlopende kosten heeft, zoals hosting, een database of AI-gebruik, kost elke klant die eenmalig betaalt je voor altijd geld. Eenmalige prijzen passen het best wanneer de kosten per gebruiker bijna nul zijn, of wanneer je updates of een nieuwe versie apart in rekening brengt.

Freemium

Een gratis niveau trekt mensen aan; een betaald niveau vangt wie echte waarde haalt. Het moeilijke is de grens ertussen. Goede grenzen volgen gebruik dat samenhangt met waarde: aantal projecten, teamleden, records, exports of geavanceerde functies. Slechte grenzen frustreren gratis gebruikers zonder het betaalde niveau aantrekkelijker te maken.

Prijzen op basis van gebruik

Betalen per gebruik is eerlijk als je kosten met het gebruik meestijgen. AI-functies zijn het duidelijkste voorbeeld, omdat elke modelaanroep iets kost. Klanten betalen graag alleen wat ze gebruiken, maar haten verrassende rekeningen. Toon het gebruik dus duidelijk en overweeg een basisabonnement met een inbegrepen tegoed.

Transactievergoedingen

Als je app kopers en verkopers verbindt, zoals een marktplaats, een boekingsplatform of een vacaturebord, dan sluit een percentage per transactie je inkomsten aan op het succes van je gebruikers. Het heeft volume nodig en brengt echte complexiteit mee: uitbetalingen aan verkopers, terugbetalingen, geschillen en soms belasting. Plan de uitbetalingskant voordat je bouwt; meestal is dat het moeilijkste deel.

Advertenties, sponsoring en affiliate-inkomsten

Advertenties leveren pas echt geld op bij grote schaal, en ze kunnen een product dat mensen aandacht geven ondermijnen. Voor niche-apps met kleinere publieken verdienen sponsoring (een relevant bedrijf betaalt voor een plaatsing) en affiliate-links (een commissie op verkopen die je doorverwijst) vaak meer per bezoeker. Label betaalde plaatsingen altijd duidelijk.

Diensten rond de app

Vooral in het begin kan het verkopen van installatie, onboarding of maatwerk naast een tool de ontwikkeling financieren en je leren wat klanten nodig hebben. Het schaalt niet zoals software, dus behandel het als een brug, niet als eindbestemming.

Een model kiezen

Beantwoord deze vragen over je app:

1. Hoe vaak gebruikt iemand hem? Dagelijks of wekelijks wijst op een abonnement. Eens of soms wijst op eenmalig of gebruiksgebaseerd.
2. Kost elk gebruik je geld? Zo ja, dan gebruiksgebaseerd of een abonnement met limieten.
3. Wie betaalt: de gebruiker of een bedrijf? Bedrijven accepteren abonnementen en facturen makkelijker dan particulieren.
4. Verbindt hij twee groepen? Overweeg transactievergoedingen.
5. Is het publiek enorm en casual? Overweeg dan pas advertenties.
6. Is er een natuurlijk “meer”? Zo ja, dan kan freemium werken.

De meeste apps kiezen één hoofdmodel en voegen een tweede toe: een abonnement met add-ons op basis van gebruik, of een gratis niveau plus een betaald plan plus diensten voor grotere klanten.

Betalingen aannemen

Voor een webapp gebruik je bijna altijd een betaalverwerker in plaats van zelf kaarten te verwerken. Stripe is een veelgebruikte keuze voor software. Alternatieven zijn Paddle en Lemon Squeezy, die optreden als “merchant of record”: zij verkopen namens jou aan je klant en regelen de btw, met hun eigen tariefstructuur. Vergelijk de prijspagina’s voordat je kiest.

Wat een verwerker afhandelt:

• Checkout: een beveiligde pagina waar klanten hun kaartgegevens invullen. Je app ziet het kaartnummer nooit.
• Abonnementen: terugkerende facturering, upgrades, opzeggingen en herhaalpogingen bij mislukte betalingen.
• Bonnetjes en facturen.
• Webhooks: berichten naar je app wanneer een betaling slaagt of mislukt of een abonnement verandert, zodat je toegang kunt geven of intrekken.

Wat de kosten betreft: vanaf september 2026 vermeldt de prijspagina van Stripe dat de standaardprijs geen opstart- of maandkosten heeft, en dat kaartbetalingen worden gerekend als een percentage plus een vast bedrag per geslaagde transactie. De exacte tarieven verschillen per land, kaarttype en extra producten zoals abonnementsfacturering. Controleer de pagina voor jouw land in plaats van te vertrouwen op een cijfer dat je elders zag.

Hoe je betalingen aan je app toevoegt doorloopt checkout, abonnementen, webhooks en testmodus stap voor stap.

App-stores versus het web

Waar je app leeft, verandert hoe je geld kunt vragen.

Webapps

Een webapp draait in de browser op elk apparaat, ook op telefoons. Er zit geen store tussenin: je kiest je betaalverwerker, stelt je prijzen in en betaalt alleen de kosten van de verwerker. Je hebt ook geen storegoedkeuring nodig om een update uit te brengen. De nadelen zijn vindbaarheid, want niemand vindt je door in een store te bladeren, en het feit dat sommige gebruikers liever apps installeren. Native versus progressieve webapps legt de verschillen uit.

Native apps in de App Store en Google Play

Distributie via de stores brengt regels met zich mee over hoe je geld vraagt:

• Apple. Vanaf september 2026 stellen Apples App Review Guidelines dat het ontgrendelen van functies of content binnen een app (abonnementen, premium content, een volledige versie) via de in-app-aankoop van Apple moet lopen. Fysieke goederen en diensten die buiten de app worden gebruikt, zoals een taxirit of een geleverd product, moeten andere betaalmethoden gebruiken. Apples Small Business Program biedt een verlaagde commissie van 15% op betaalde apps en in-app-aankopen aan ontwikkelaars die het voorgaande kalenderjaar tot 1 miljoen USD aan opbrengsten hadden, en aan ontwikkelaars die nieuw zijn in de store. Boven die drempel geldt het standaardtarief. In sommige regio’s, waaronder de EU, gelden andere voorwaarden.
• Google Play. Google rekent een servicevergoeding op digitale goederen en abonnementen die via Play-facturering worden verkocht. Vanaf september 2026 toont de servicekostenpagina tarieven die in 2026 per regio veranderen, met verschillende tarieven voor abonnementen, nieuwe versus bestaande installaties en omzetdrempels. Lees de actuele pagina voor je markten voordat je prijzen plant.

De regels in beide stores zijn de afgelopen jaren vaak veranderd, vaak per regio. Behandel elk cijfer, ook de hierboven genoemde, als iets om op de officiële pagina na te kijken voordat je je vastlegt.

Voordat je geld gaat vragen: een checklist

• Iemand heeft gezegd dat hij zou betalen. Idealiter heeft iemand al betaald. Vooraf verkopen voordat je bouwt is het sterkste signaal dat je kunt krijgen.
• De betaalstroom is van begin tot eind getest in de testmodus van de verwerker: betalen, mislukken, annuleren, terugbetalen.
• Toegang volgt betaling. Betalen ontgrendelt de juiste functies; opzeggen of een mislukte verlenging haalt ze weg.
• De prijzen staan op een duidelijke pagina met wat elk plan bevat.
• Algemene voorwaarden, privacybeleid en retourbeleid bestaan. Vraag lokaal advies over belasting en consumentenregels; die verschillen per land.
• Je kent je kosten per gebruiker, zoals hosting, database en AI-gebruik, zodat elke prijs ze dekt.

Veelgemaakte fouten

• Te lang wachten met vragen om geld. Gratis gebruikers vertellen wat ze leuk vinden; betalende gebruikers vertellen wat ze waarderen.
• Te veel plannen. Twee of drie niveaus is voldoende om mee te beginnen.
• Lopende kosten negeren. Vooral bij AI-functies kunnen zware gebruikers meer kosten dan ze betalen.
• Onduidelijk opzeggen. Maak het makkelijk. Het bouwt vertrouwen op en beperkt geschillen.
• Aannemen dat storeregels eenvoudig zijn. Controleer ze voordat je een native app rond een betaalmodel bouwt.

Een betaalde app bouwen met Mythex

Mythex bouwt webapps, dus op het web neem je betalingen aan via je eigen verwerker en zit er geen appstore tussenin. Voor Stripe voeg je je eigen Stripe-sleutels toe als projectgeheimen en vraag je de agent om Checkout toe te voegen. Je test met Stripe-testkaarten in de preview en publiceert daarna. Het Stripe-recept in de docs bevat de stappen. Mythex biedt geen Stripe-koppeling met één klik. Op Pro kan het de app ook als Android- en iPhone-app verpakken; zodra je in de stores zit, gelden de regels van Apple en Google voor betalingen in de app. Voor ideeën die de moeite waard zijn om geld voor te vragen, zie micro-SaaS-ideeën. Als je klaar bent om klanten te vinden, lees dan hoe je een app lanceert en je eerste gebruikers krijgt.

Veelgestelde vragen