Braucht deine KI-gebaute App ein echtes Backend? So findest du es heraus, bevor du eins hinzufügst

Der Moment, in dem du anfängst zu zweifeln

Ein Backend ist einfach Code, der irgendwo anders läuft als im Browser – er erledigt Dinge, die der Browser nicht erledigen soll, wie Geld abbuchen oder Geheimnisse hüten, und er spricht mit einer Datenbank. Die meisten KI-gebauten Apps tun das bereits, auch wenn es nicht so aussieht, wie du es dir vorgestellt hast.

Deine App funktioniert. Nutzer melden sich an. Features gehen live. Und dann beschleicht dich dieses Gefühl: Sollte da nicht ein “echtes Backend” sein? Alle reden über Backends. Ernsthafte Apps haben Backends. Dein Builder hat dir ein TypeScript-in-React-Ding gegeben, und du fängst an zu denken, das sei vielleicht nicht … professionell genug.

Hier die Wahrheit: Dieses Gefühl liegt meistens falsch. Nichts von dem, was ein Backend tut, ist Magie – und deine KI-gebaute App macht es möglicherweise schon. Falls nicht, löst ein hinzugefügtes Backend nicht das eigentliche Problem – was auch immer wirklich kaputt ist.

In diesem Beitrag geht es darum, den Unterschied zu erkennen.

Wofür ist ein Backend eigentlich da?

Ein Backend existiert aus genau drei Gründen: Geld abwickeln, Geheimnisse sicher aufbewahren und als einzige Quelle der Wahrheit fungieren, wenn mehr als eine Person dieselben Daten bearbeitet.

Geld abwickeln. Wenn deine App Zahlungen entgegennimmt oder Nutzer belastet, verlangt der Zahlungsdienstleister ein Backend. Dein Browser kann Stripe nicht direkt mit deinem geheimen API-Schlüssel ansprechen (du würdest den Schlüssel in clientseitigen Code packen, sichtbar für jeden). Du brauchst also einen Server, der den Schlüssel sicher aufbewahrt, Anfragen vom Browser entgegennimmt und stellvertretend für den Nutzer mit Stripe spricht. Das ist ein Backend. Es muss nicht ausgefeilt sein – eine einzelne Node-Funktion reicht für die meisten Apps –, aber es muss existieren.

Geheimnisse sicher aufbewahren. API-Schlüssel, Datenbank-Passwörter, Auth-Tokens – die können nicht im Browser leben, weil jeder, der deine App nutzt, sie auslesen kann. Wenn deine KI-gebaute App einen externen Dienst aufrufen muss, der Authentifizierung verlangt, kann der Browser das nicht allein. Die App spricht mit deinem Backend, das den Schlüssel besitzt und den externen Dienst aufruft. Deine Geheimnisse bleiben geheim.

Eine Quelle der Wahrheit für Daten. Wenn zwei Nutzer deine App gleichzeitig verwenden und beide versuchen, dieselben Daten zu ändern, brauchst du eine zentrale Instanz, die entscheidet, wessen Änderung gewinnt. Der Browser kann nicht Schiedsrichter spielen – zwei Browser können sich nicht gegenseitig sehen. Du brauchst also einen Server, der sagt: “Alice bekommt die Namensänderung, Bobs kam 30 Millisekunden später an, also gilt seine nicht.” Dieser Server ist ein Backend. Deshalb ist der Datenbank-Abschnitt so wichtig – du brauchst einen Ort, an dem alle Daten tatsächlich leben.

Beachte, was nicht auf der Liste steht: Performance, Professionalität, Skalierbarkeit, weil-alle-eins-haben. Das sind die Gefühle, die dich dazu verleiten, Komplexität hinzuzufügen, die du nicht brauchst.

Woher weißt du, dass du wirklich ein Backend brauchst?

Drei Signale bedeuten, dass du wirklich eins brauchst: Die App ist langsam aus einem Grund, den der Browser allein nicht beheben kann, du brauchst Code, der irgendwo läuft, wo der Nutzer ihn nicht sehen oder unterbrechen kann, oder zwei Nutzer überschreiben sich gegenseitig die Daten. So findest du heraus, welcher Fall – falls überhaupt einer – auf dich zutrifft.

“Es ist langsam.” Wenn Nutzer Langsamkeit melden, liegt das Problem meist an einem von drei Dingen: Der Browser leistet zu viel Arbeit (CPU-lastig, schlechter Algorithmus, zu viel DOM-Rendering), das Netzwerk ist langsam (traurig, aber wahr), oder die Datenbank ist langsam (zu viele Abfragen, falsche Indizes – deine KI-gebaute App spricht bereits mit einer Datenbank, meist einer guten). Ein echtes Backend behebt keine CPU-Arbeit im Browser. Ein echtes Backend behebt keine Netzwerklatenz (Physik ist hart). Ein Backend kann bei Datenbankabfragen helfen, indem es Caching oder klügere Abfragemuster hinzufügt – aber dein Builder hat daran wahrscheinlich schon gedacht.

Eine echte Geschichte über Langsamkeit: Eine Todo-App war beim Laden der Liste träge. Der Entwickler dachte: “Ich brauche ein echtes Backend.” Das tatsächliche Problem: Die App lud jedes Mal alle 5.000 Todos, statt nur die ersten 50 mit einem “Mehr laden”-Button zu laden. An einem Nachmittag behoben, ohne das Backend anzufassen. Das Backend war nicht das Problem.

“Ich möchte Code ausführen, den der Nutzer nicht sehen soll.” Das ist der einzige Grund, der wirklich Sinn ergibt, und er ist seltener, als du denkst. Beispiele: eine E-Mail versenden, nachdem sich ein Nutzer angemeldet hat (du willst, dass dieser Code läuft, selbst wenn er den Tab schließt), einen Hintergrundjob laufen lassen, der über Nacht Dateien verarbeitet, eine externe API nach Zeitplan aufrufen. Das sind valide Gründe. Du brauchst tatsächlich etwas, das irgendwo auf einem Server läuft. Aber es muss kein vollständiges Backend mit Authentifizierung, Routing und Datenbanken sein. Es kann eine einzelne “Cloud-Funktion” sein, die nach Zeitplan läuft oder von einem Webhook aufgerufen wird. Viel einfacher als ein ganzes Backend.

“Mehrere Nutzer ändern gleichzeitig dieselben Daten, und ich verliere Aktualisierungen.” Das ist real. Wenn du siehst, dass “Alices Änderungen verschwunden sind” oder “zwei Personen haben dasselbe Formular bearbeitet, und die Änderungen der zweiten Person haben gewonnen”, hast du ein Konflikt-Problem. Manche Datenbanken handhaben das besser als andere, und manche KI-Builder setzen standardmäßig auf Datenbanken, die es nicht gut handhaben. Aber die Lösung ist nicht immer ein ganzes Backend – es könnte bedeuten, die Datenbank zu wechseln, Locking hinzuzufügen oder optimistische Nebenläufigkeit einzuführen (ein schicker Begriff für “die alte Versionsnummer behalten und vor einem Update vergleichen”). Frag deinen Builder, ob er die Datenbank wechseln oder Versions-Tracking hinzufügen kann. Vielleicht brauchst du kein Backend – du brauchst ein klügeres Datenbank-Setup.

Was wie ein Backend-Problem aussieht, aber keins ist

Drei Dinge werden fälschlich für Backend-Probleme gehalten und sind keine: JavaScript, das an einem Ort lebt, keine separate API-Schicht, und allgemeine Sicherheitssorgen ohne konkretes Problem dahinter.

“Der Code ist JavaScript und alles ist an einem Ort.” Viele erfolgreiche Apps sind JavaScript im Browser, das mit einer echten Datenbank spricht (Firebase, Supabase, MongoDB Atlas, was auch immer dein Builder eingerichtet hat). Es gibt keinen “echten Backend”-Server. Alles funktioniert. Dass der Code in einer Sprache an einem Ort liegt, heißt nicht, dass er nicht echt ist. JavaScript funktioniert.

“Es gibt keine separate API-Schicht.” Dein Browser spricht direkt mit deiner Datenbank. Viele Leute denken instinktiv: “Das kann nicht richtig sein, dazwischen sollte eine API sein.” Aber wenn die API buchstäblich nur “wähle aus dieser Tabelle aus und gib sie zurück” oder “füge in diese Tabelle ein” macht, fügt die mittlere Schicht nichts hinzu. Sie ist nur Overhead. Deine Datenbank ist bereits eine API. Ruf sie direkt auf, wenn du kannst.

“Ich mache mir Sorgen um die Sicherheit.” Die meisten KI-gebauten Apps kommen mit sinnvollen Standardeinstellungen: Passwörter werden gehasht, SQL-Injection ist nicht möglich (die Datenbank-Bibliothek verhindert das), Geheimnisse bleiben vom Client fern. Wenn du dir wirklich Sorgen machst, ist der richtige Schritt, deinen Builder zu fragen, ob er diese Dinge tut – nicht reflexartig ein Backend hinzuzufügen. Ein schlecht gebautes Backend ist verwundbarer als ein gut gebautes Frontend.

Der ehrliche Entscheidungsbaum

So findest du es heraus, ohne zu raten:

Kann deine App das, was sie gerade tut, ohne Backend tun? Wenn ja, weiter zu 2. Wenn nein, hast du bereits ein Backend (oder musst eins bauen). Weiter geht’s. (Deine KI-gebaute App hat vielleicht schon eins.)
Ist das, was du hinzufügen willst, etwas, das der Browser grundsätzlich nicht kann? Geld abbuchen? Definitiv. E-Mail versenden? Ja. Eine externe API mit geheimem Schlüssel aufrufen? Ja. Irgendwas anderes? Wahrscheinlich nicht. Wenn es etwas ist, das der Browser könnte, aber es langsam ist, weiter zu 3. Wenn es etwas ist, das der Browser nicht kann, brauchst du ein Backend.
Verschwindet die Langsamkeit, wenn du das eigentliche Problem behebst? Weniger laden? Klüger cachen? Anfragen bündeln? Eine bessere Datenbank nutzen? Der Trick: Finde zuerst heraus, was wirklich langsam ist. Füge ein Backend erst hinzu, nachdem du die naheliegenden Lösungen ausgeschöpft hast. Denn ein Backend hinzuzufügen behebt keinen langsamen Algorithmus – es verschiebt ihn nur auf eine andere Maschine.
Wenn du ein Backend hinzufügst – löst es das Problem tatsächlich? Das ist die Falle. Du fügst ein Backend hinzu, um die “Performance zu verbessern”, und die Latenz wird schlechter, weil du jetzt Netzwerkaufrufe an dein Backend machst, das wiederum Netzwerkaufrufe an die Datenbank macht – was du vom Browser aus in einem Hop hättest erledigen können. Erst messen. Dann handeln.

Brauchst du ein vollständiges Backend oder nur eine Cloud-Funktion?

Wenn das, was du willst, in eine einzelne Funktion passt, die ein paar Sekunden läuft und dann stoppt, brauchst du eine Cloud-Funktion, kein vollständiges Backend. Hier der Geruchstest.

Denk darüber nach, was du das Backend tun lassen willst. Stell dir jetzt vor, du schreibst es als einzelne JavaScript-Funktion (vielleicht 100 Zeilen), die bei Aufruf ein paar Sekunden läuft und dann stoppt. Passt es in diese Box?

Zahlungs-Webhooks verarbeiten? Ja.
Eine Willkommens-E-Mail versenden? Ja.
Eine Datei vor dem Upload validieren? Ja.
Einen nächtlichen Bericht erstellen? Ja (na ja – du würdest sie nach Zeitplan aufrufen).

Wenn die Antwort Ja lautet, brauchst du kein “echtes Backend”. Du brauchst eine Cloud-Funktion. Vercel, AWS Lambda, Google Cloud Functions, was auch immer. Es ist günstiger, einfacher, und du musst keinen Server hüten.

Wenn die Antwort Nein lautet – wenn du etwas brauchst, das ständig läuft, Tausende Anfragen verarbeitet, mit komplexer Geschäftslogik –, dann denkst du tatsächlich über ein echtes Backend nach, und dieses Gespräch ist wichtiger. Aber ehrlich gesagt ist das selten bei Apps, die Leute mit KI bauen. Das meiste, was wie “Backend-Arbeit” aussieht, ist nur “diese API aufrufen” oder “diese Daten speichern”, was dein Builder wahrscheinlich schon abdeckt.

Die richtige Frage an deinen Builder

Bevor du irgendetwas hinzufügst, stell deinem Builder eine Frage: Was ist gerade kaputt, das ein Backend tatsächlich beheben würde?

Wenn er eine konkrete Antwort hat – “wir müssen Geld abbuchen”, “wir müssen eine API mit geheimem Schlüssel aufrufen”, “wir haben Datenkonflikte” –, super. Dann weißt du, worauf du hinarbeitest.

Wenn die Antwort lautet “na ja, echte Apps haben Backends”, ist das ein Gefühl, kein Grund. Es ist dasselbe Gefühl, das dich dazu bringt, einer App, die niemand teilt, Nutzerkonten hinzuzufügen, oder ein Datenbankschema mit fünfzehn Tabellen zu bauen, wenn du eigentlich drei Dinge hast. Es ist der Geruch von Scope Creep, der einen Backend-Hut trägt.

Die meisten erfolgreichen Ein-Personen-Apps haben kein “echtes Backend” in dem Sinn, den du dir vorstellst. Sie haben eine Datenbank (dein Builder hat die wahrscheinlich eingerichtet). Vielleicht haben sie eine oder zwei Funktionen, die nach Zeitplan laufen. Aber der Code, der im Browser läuft, erledigt die Arbeit, spricht direkt mit der Datenbank und liefert Features aus – ohne mittlere Schicht.

Deine App ist wahrscheinlich so, wie sie ist, völlig in Ordnung. Das Gefühl, dass sie es nicht ist, ist meist der Klang von Ehrgeiz, nicht von Wahrheit. Füge ein Backend hinzu, wenn es ein echtes Problem löst – nicht, weil du das Gefühl hast, du solltest.

Wenn du das nächste Mal ein Feature skizzierst, frag dich: Ist das etwas, das der Browser grundsätzlich nicht kann? Oder ist es etwas, von dem ich denke, es bräuchte ein Backend, weil ich das Wort schon oft genug gehört habe? Die Antworten auf diese beiden Fragen sind unterschiedlich, und nur eine davon ist deine Aufgabe.