Heeft je AI-gebouwde app een echte backend nodig? Zo weet je het voordat je er een toevoegt

Het moment waarop je je begint af te vragen

Een backend is simpelweg code die ergens anders draait dan in de browser — hij doet dingen die de browser niet hoort te doen, zoals geld afschrijven of geheimen bewaren, en hij praat met een database. De meeste met AI gebouwde apps doen al iets van dit alles, ook al ziet het er misschien niet uit zoals je het je had voorgesteld.

Je app werkt. Gebruikers melden zich aan. Functies worden uitgerold. En dan bekruipt je dat gevoel: zou er niet een “echte backend” moeten zijn? Iedereen heeft het over backends. Serieuze apps hebben backends. Jouw builder gaf je iets van TypeScript-in-React en je begint te denken dat dat misschien niet… professioneel genoeg is.

Hier is de waarheid: dat gevoel klopt meestal niet. Niets van wat een backend doet is magie, en je met AI gebouwde app doet het waarschijnlijk al. Als dat niet zo is, lost een backend toevoegen het echte probleem niet op — wat er ook daadwerkelijk kapot is.

Deze post gaat over het herkennen van het verschil.

Waar dient een backend eigenlijk voor?

Een backend bestaat om precies drie redenen: geld afhandelen, geheimen veilig houden, en fungeren als enige bron van waarheid wanneer meer dan één persoon dezelfde data bewerkt.

Geld afhandelen. Als je app betalingen int of gebruikers laat betalen, vereist de betalingsverwerker een backend. Je browser kan Stripe niet rechtstreeks benaderen met je geheime API-sleutel (dan zou je die sleutel in client-side code zetten, zichtbaar voor iedereen). Je hebt dus een server nodig die de sleutel veilig bewaart, verzoeken van de browser accepteert en namens de gebruiker met Stripe praat. Dat is een backend. Hij hoeft niet ingewikkeld te zijn — voor de meeste apps volstaat één enkele Node-functie — maar hij moet wel bestaan.

Geheimen veilig houden. API-sleutels, databasewachtwoorden, authenticatietokens — die kunnen niet in de browser leven, want iedereen die je app gebruikt kan ze uitlezen. Als je met AI gebouwde app een externe dienst moet aanroepen die authenticatie vereist, kan de browser dat niet alleen. De app praat dan met je backend, die de sleutel heeft en de externe dienst aanroept. Zo blijven je geheimen geheim.

Eén bron van waarheid voor data. Als twee gebruikers je app tegelijk gebruiken en beiden dezelfde data proberen te wijzigen, heb je een centrale autoriteit nodig die beslist wiens wijziging wint. De browser kan niet als scheidsrechter optreden — twee browsers kunnen elkaar niet zien. Je hebt dus een server nodig die zegt: “Alice krijgt de naamswijziging, Bobs wijziging kwam 30 milliseconden later binnen dus die geldt niet.” Die server is een backend. Daarom is het databasegedeelte belangrijk — je hebt één plek nodig waar alle data daadwerkelijk leeft.

Let op wat er niet op de lijst staat: prestaties, professionaliteit, schaalbaarheid, iedereen-heeft-er-een. Dat zijn de gevoelens die je verleiden tot complexiteit die je niet nodig hebt.

Hoe weet je of je écht een backend nodig hebt?

Drie signalen betekenen dat je echt een backend nodig hebt: de app is traag om een reden die de browser niet zelf kan oplossen, je hebt code nodig die draait ergens waar de gebruiker niet bij kan of het niet kan onderbreken, of twee gebruikers overschrijven elkaars data. Hier lees je hoe je bepaalt welke, als überhaupt één, op jou van toepassing is.

“Het is traag.” Als gebruikers traagheid melden, is het probleem meestal een van drie dingen: de browser doet te veel werk (CPU-gebonden, slecht algoritme, te veel DOM renderen), het netwerk is traag (jammer maar waar), of de database is traag (te veel queries, verkeerde indexen — je met AI gebouwde app praat al met een database, meestal een goede). Een echte backend lost geen CPU-werk in de browser op. Een echte backend lost geen netwerklatentie op (natuurkunde is hardnekkig). Een backend kán helpen bij databasequeries door caching of slimmere querypatronen toe te voegen, maar je builder heeft daar waarschijnlijk al aan gedacht.

Een echt traagheidsverhaal: een to-do-app was traag bij het laden van de lijst. De ontwikkelaar dacht: “ik heb een echte backend nodig.” Het werkelijke probleem: de app laadde elke keer alle 5.000 to-do’s, in plaats van gewoon de eerste 50 te laden met een “meer laden”-knop. Opgelost in een middag, zonder de backend aan te raken. De backend was het probleem niet.

“Ik wil code draaien die de gebruiker niet mag zien.” Dit is de enige reden die echt hout snijdt, en hij komt minder vaak voor dan je denkt. Voorbeelden: een e-mail sturen nadat een gebruiker zich heeft aangemeld (je wilt dat die code draait ook als ze het tabblad sluiten), een achtergrondtaak die ‘s nachts bestanden verwerkt, een externe API op een schema aanroepen. Dit zijn geldige redenen. Je hebt dan inderdaad iets nodig dat ergens op een server draait. Maar dat hoeft geen volledige backend te zijn met authenticatie en routering en databases. Het kan een enkele “cloudfunctie” zijn die op een schema draait of via een webhook wordt aangeroepen. Veel eenvoudiger dan een hele backend.

“Meerdere gebruikers wijzigen tegelijk dezelfde data en ik verlies updates.” Dit is een echt probleem. Als je “Alice’s wijzigingen zijn verdwenen” of “twee mensen bewerkten hetzelfde formulier en de wijzigingen van de tweede persoon wonnen het” ziet gebeuren, heb je een conflictprobleem. Sommige databases handelen dit beter af dan andere, en sommige AI-builders kiezen standaard voor databases die dat niet goed doen. Maar de oplossing is niet altijd een hele backend — het kan ook zijn dat je van database wisselt, locking toevoegt, of optimistic concurrency toevoegt (een chique term voor “bewaar het oude versienummer en vergelijk voordat je een update toestaat”). Vraag je builder of ze van database kunnen wisselen of versietracking kunnen toevoegen. Misschien heb je geen backend nodig, maar een slimmere database-opzet.

Wat lijkt op een backendprobleem, maar is dat niet?

Drie dingen worden ten onrechte aangezien voor backendproblemen: JavaScript dat allemaal op één plek leeft, geen aparte API-laag, en algemene bezorgdheid over veiligheid zonder concreet probleem.

“De code is JavaScript en zit allemaal op één plek.” Talloze succesvolle apps zijn JavaScript in de browser, pratend met een echte database (Firebase, Supabase, MongoDB Atlas, wat je builder ook heeft opgezet). Er is geen “echte backend”-server. Alles werkt gewoon. Dat de code in één taal op één plek zit, betekent niet dat hij niet echt is. JavaScript werkt.

“Er is geen aparte API-laag.” Je browser praat rechtstreeks met je database. Veel mensen denken dan instinctief: “dat klopt niet, daar zou een API tussen moeten zitten.” Maar als die API letterlijk alleen “selecteer uit deze tabel en geef het terug” of “voeg toe aan deze tabel” doet, voegt die tussenlaag niets toe. Het is puur overhead. Je database is al een API. Roep hem rechtstreeks aan als dat kan.

“Ik maak me zorgen over veiligheid.” De meeste met AI gebouwde apps komen met verstandige standaardinstellingen: wachtwoorden worden gehasht, SQL-injectie is niet mogelijk (de databasebibliotheek voorkomt dat), geheimen blijven buiten de client. Als je je hier echt zorgen over maakt, is het beste wat je kunt doen je builder vragen of ze deze dingen doen, in plaats van reflexmatig een backend toe te voegen. Een slecht gebouwde backend is kwetsbaarder dan een goed gebouwde frontend.

De eerlijke beslisboom

Zo achterhaal je dit zonder te gokken:

Kan je app doen wat hij nu doet, zonder backend? Zo ja, ga naar 2. Zo nee, dan heb je al een backend (of moet je er een bouwen). Ga verder. (Je met AI gebouwde app heeft er misschien al een.)
Is wat je wilt toevoegen iets wat de browser fundamenteel niet kan? Geld afschrijven? Zeker weten. Een e-mail versturen? Jazeker. Een externe API aanroepen met een geheime sleutel? Ja. Iets anders? Waarschijnlijk niet. Als het iets is wat de browser wel kan maar traag doet, ga naar 3. Als het iets is wat de browser niet kan, heb je een backend nodig.
Verdwijnt de traagheid als je het eigenlijke probleem oplost? Minder dingen laden? Slimmer cachen? Verzoeken bundelen? Een betere database gebruiken? De truc is: zoek eerst uit wat er echt traag is. Voeg pas een backend toe nadat je de voor de hand liggende oplossingen hebt uitgeput. Want een backend toevoegen lost een traag algoritme niet op — het verplaatst het alleen naar een andere machine.
Als je een backend toevoegt, lost dat het probleem daadwerkelijk op? Dit is de valkuil. Je voegt een backend toe om “de prestaties te verbeteren,” en de latentie wordt juist slechter, omdat je nu netwerkverzoeken doet naar je backend, die op zijn beurt netwerkverzoeken doet naar de database — iets wat je in één stap vanuit de browser had kunnen doen. Meet eerst. Voeg daarna pas toe.

Heb je een volledige backend nodig, of gewoon een cloudfunctie?

Als wat je wilt past binnen één enkele functie die een paar seconden draait en dan stopt, heb je een cloudfunctie nodig, geen volledige backend. Hier is de ruiktest.

Denk na over wat je de backend wilt laten doen. Stel je nu voor dat je het schrijft als één enkele JavaScript-functie (misschien 100 regels) die een paar seconden draait wanneer hij wordt aangeroepen en dan stopt. Past het in dat kader?

Betalingswebhooks afhandelen? Ja.
Een welkomstmail sturen? Ja.
Een bestand valideren voordat het wordt geüpload? Ja.
Een nachtelijk rapport draaien? Ja (min of meer — je zou hem op een schema aanroepen).

Als het antwoord ja is, heb je geen “echte backend” nodig. Je hebt een cloudfunctie nodig. Vercel, AWS Lambda, Google Cloud Functions, wat dan ook. Het is goedkoper, eenvoudiger, en je hoeft geen server op te passen.

Als het antwoord nee is — als je iets nodig hebt dat continu draait, duizenden verzoeken afhandelt, met complexe bedrijfslogica — dan denk je aan een echte backend en is dat gesprek belangrijker. Maar eerlijk gezegd komt dat zelden voor bij apps die mensen met AI bouwen. Het meeste wat op “backendwerk” lijkt, is gewoon “roep deze API aan” of “sla deze data op,” wat je builder waarschijnlijk al afhandelt.

De echte vraag om je builder te stellen

Voordat je iets toevoegt, stel je builder één vraag: wat is er nu kapot dat een backend daadwerkelijk zou oplossen?

Als ze een concreet antwoord hebben — “we moeten geld afschrijven,” “we moeten een API aanroepen met een geheime sleutel,” “we hebben dataconflicten” — geweldig. Dan weet je waar je naartoe werkt.

Als het antwoord is “nou, echte apps hebben backends,” is dat een gevoel, geen reden. Het is hetzelfde gevoel dat je gebruikersaccounts wil laten toevoegen aan een app die niemand deelt, of een databaseschema met vijftien tabellen terwijl je eigenlijk drie dingen hebt. Het is de geur van scope creep, vermomd als backend.

De meeste succesvolle solo-apps hebben geen “echte backend” in de zin die jij je voorstelt. Ze hebben een database (je builder heeft die waarschijnlijk al opgezet). Misschien draait er een functie of twee op een schema. Maar de code die in de browser draait doet het werk, praat rechtstreeks met de database, en levert functies uit zonder tussenlaag.

Je app is waarschijnlijk prima zoals hij is. Het gevoel dat dat niet zo is, is meestal het geluid van ambitie, niet van waarheid. Voeg een backend toe wanneer hij een echt probleem oplost, niet omdat je het gevoel hebt dat het zo hoort.

De volgende keer dat je een functie aan het schetsen bent, vraag jezelf af: is dit iets wat de browser fundamenteel niet kan? Of is het iets waarvan ik denk dat het een backend nodig heeft omdat ik dat woord vaak genoeg heb gehoord? Het antwoord op die twee vragen is verschillend, en slechts één ervan is jouw taak.