Development

Enshittification of appification? Waarom we steeds vaker een eigen app bouwen

Geschreven door Sam Serrien · 9 november 2026

Een rommelige stapel grijze, gebarsten glazen app-tegels met slotjes en waarschuwingen is via een groene lichtlijn verbonden met een opgeruimde set groen oplichtende glazen apps: een smartphone, een dashboard en een kalender met een vinkje

Je hebt het woord waarschijnlijk al zien passeren: enshittification. Het is geen nette term (excuses daarvoor), maar wel een die blijft hangen, omdat iedereen het gevoel herkent. De tools waar je elke dag mee werkt, worden langzaam slechter. Duurder, trager, voller met meldingen, upsells en AI-knoppen waar je nooit om vroeg. In dit artikel leg ik uit wat het woord precies betekent, en waarom wij het tegenovergestelde zien gebeuren aan de andere kant: een eigen app laten bouwen was nog nooit zo haalbaar. Noem het appification.

Wat is enshittification?

Het woord komt van de Canadees-Britse schrijver Cory Doctorow. Hij gebruikte het voor het eerst eind 2022, en in 2023 riep de American Dialect Society het uit tot woord van het jaar. In 2025 schreef hij er een volledig boek over.

Doctorow beschrijft hoe online platformen achteruitgaan, in drie stappen:

Eerst is het platform goed voor zijn gebruikers. Het is gratis of goedkoop, het werkt goed en iedereen stapt in.
Daarna verschuift de waarde naar de zakelijke klanten, zoals adverteerders en verkopers. Gebruikers zitten er intussen vast, dus die mogen wat inleveren.
Tot slot wordt iedereen uitgeknepen voor de aandeelhouders. Zowel gebruikers als zakelijke klanten krijgen minder voor meer geld, omdat vertrekken te veel moeite kost.

Het kernwoord daarin is vastzitten. Zolang het moeilijk is om te vertrekken, is er weinig dat een platform tegenhoudt om het een beetje slechter te maken. Volgens Doctorow houden vooral concurrentie, regelgeving, de macht van werknemers en de vrijheid van gebruikers om zelf in te grijpen of over te stappen dat proces in toom.

En AI dan?

Doctorow had het oorspronkelijk niet over AI. Maar het woord valt vandaag vaak wanneer er weer eens een AI-assistent in een product geduwd wordt, een chatbot in de plaats komt van een mens bij support, of een functie die je al jaren gebruikte plots achter een duurder AI-abonnement verdwijnt. Dat is geen nieuw probleem, het is hetzelfde patroon in een nieuw jasje.

Waarom je dat als bedrijf voelt

Bij een social media app is het vervelend. Bij de software waarop je bedrijf draait, kost het geld en tijd. En de meeste kmo's draaien vandaag op een stapel abonnementen: een tool voor planning, een voor formulieren, een voor offertes, een voor klantenopvolging, en een paar spreadsheets om het allemaal aan elkaar te knopen.

Dat werkt, tot het niet meer werkt:

De prijs gaat omhoog, of je betaalt plots per gebruiker in plaats van per bedrijf.
Een functie die je nodig hebt, verhuist naar een duurder pakket.
De tool doet honderd dingen, waarvan jij er drie gebruikt. De andere 97 staan je in de weg.
Je proces past zich aan de tool aan, in plaats van omgekeerd. Er wordt overgetypt, gekopieerd en geplakt tussen systemen die niet met elkaar praten.
Je data zit vast. Exporteren kan in theorie, maar in de praktijk krijg je een CSV waar niemand iets mee kan.

Geen van die dingen is op zich een ramp. Maar samen kosten ze elke week uren, en die uren zie je nergens op een factuur staan.

De andere kant: appification

Hier wordt het interessant. Terwijl veel grote platformen slechter worden, is een eigen app bouwen de laatste jaren veel toegankelijker geworden. Moderne frameworks nemen veel standaardwerk uit handen, hosting is goedkoper en eenvoudiger, en AI helpt ontwikkelaars om sneller te bouwen en te testen. De drempel ligt een heel stuk lager dan een paar jaar geleden.

Dat verandert de rekensom. Vroeger was software op maat iets voor grote bedrijven met een groot budget. Een kleine app voor één proces was te duur om de moeite te zijn. Vandaag kan het wel, en daarom bouwen we steeds vaker kleine, gerichte apps voor dingen waarvoor je vroeger gewoon een abonnement nam of een spreadsheet bijhield.

Denk aan:

Een intakeformulier dat meteen een dossier, een planning en een bevestigingsmail aanmaakt
Een klantenportaal waar klanten zelf hun documenten, afspraken of bestellingen opvolgen
Een mobiele app voor medewerkers op de baan, die ook werkt met een slechte verbinding
Een intern dashboard dat drie spreadsheets en een mailbox vervangt
Een koppeling tussen twee tools die niet met elkaar praten, zodat niemand meer moet overtypen

Het hoeft niet groot te zijn. De beste apps die we bouwen, doen vaak maar een paar dingen, maar die doen ze precies zoals jij werkt.

Een rekenvoorbeeld

Stel dat drie mensen in je team elk een halfuur per dag kwijt zijn aan gegevens overtypen tussen systemen. Over een werkjaar is dat al gauw meer dan 300 uur. Een kleine app die dat automatiseert, verdient zich dan snel terug. Reken het gerust eens uit voor je eigen processen, de uitkomst valt vaak hoger uit dan je denkt.

Zo werken we zelf

We zeggen dit niet alleen omdat we apps verkopen. GeNx draait zelf bijna volledig op software die we zelf gebouwd hebben. Voor onze eigen werking gebruiken we:

Een eigen native app voor onze interne werking, waarin de dagelijkse dingen samenkomen.
Een eigen app voor facturatie, die werkt zoals wij factureren, en niet omgekeerd.
Een eigen beheertool voor hosting, waarmee we de websites en servers van onze klanten opvolgen.
Een eigen boekingstool, my.genx.be, waar klanten zelf een afspraak inplannen.
TinyDesk voor feedback en support van klanten.

Ook naast GeNx werk ik zo. Ik geef les aan de Karel de Grote Hogeschool, en om mijn eigen werk daar vlotter te laten lopen, bouwde ik een native Canvas client: een desktop app die Canvas en het lessenrooster samenbrengt, ook offline werkt en een nieuwe cursus in een paar stappen opzet. Samen met de andere makers binnen HYPERCHICKEN bouwden we TinyForms en Aptly, tools voor formulieren en afspraakplanning. En porpor is een eigen app voor iPhone en Android, gewoon omdat we het een leuk idee vonden.

Voor klanten bouwen we hetzelfde soort dingen. Mijn Middenvijver is bijvoorbeeld een buurtportaal voor de bewoners rond het park waar Live is Live plaatsvindt: één registratie, en buren krijgen voordeeltickets, doorlaatbewijzen en updates.

Het voordeel van zo te werken: als iets ons stoort, passen we het aan. Er komt geen prijsverhoging uit het niets, en geen functie die verdwijnt omdat een productteam ergens anders andere prioriteiten heeft.

Wanneer is een eigen app geen goed idee?

Eerlijk is eerlijk: niet alles moet op maat. Voor de meeste standaarddingen is een goed bestaand product de betere keuze.

Een eigen app is zinvol als

Het proces typisch is voor jouw bedrijf
Je team er elke dag tijd aan verliest
Je data uit meerdere tools moet samenbrengen
Je klanten of medewerkers er rechtstreeks mee werken
De bestaande tools je dwingen om anders te werken

Neem beter een bestaand product voor

Boekhouding en facturatie
E-mail en agenda
Wachtwoordbeheer
Processen die je maar een paar keer per jaar doet
Dingen die overal hetzelfde werken

Bouwen is niet hetzelfde als onderhouden

AI maakt bouwen sneller, maar een app moet daarna ook gehost, beveiligd en up-to-date gehouden worden. Een app die iemand in een weekend in elkaar klikt met een AI-tool werkt vaak verrassend goed, tot er iets misgaat en niemand nog weet hoe hij in elkaar zit. Reken onderhoud dus altijd mee, en zorg dat iemand de code echt begrijpt.

Hoe begin je eraan?

Begin klein. Kies één proces dat elke week tijd kost en waar iedereen in je team een beetje van zucht. Schrijf op wat er nu gebeurt, stap voor stap, en waar het vastloopt. Vaak is dat al genoeg om te zien of een kleine app het verschil kan maken.

Daarna bouwen we een eerste versie die precies dat ene probleem oplost. Werkt het, dan kan je verder uitbreiden. Werkt het niet zoals verwacht, dan ben je niet veel kwijt en weet je wel veel meer.