Wenn Sie sich für den Tech-Stack Ihrer Web-App entscheiden, wählen Sie nicht nur ein Entwicklungserlebnis. Sie wählen ein Abrechnungsmodell. Jahrelang wurde die visuelle Entwicklung von einfachen Hosting-Plänen gesteuert. Man zahlte eine feste monatliche Gebühr für eine Stufe und erhielt eine festgelegte Serverkapazität.
Das änderte sich, als Bubble Workload Units (WUs) einführte. Anstatt für den visuellen Platz oder Datenbankgrößenbeschränkungen zu berechnen, begannen sie, jede einzelne Aktion abzurechnen, die Ihre Datenbank, Ihr Logiksystem und Ihre Seitenaufrufe ausführen. Ungefähr zur gleichen Zeit führte der Aufstieg von “Vibe Coding” und KI-Buildern ein anderes Abrechnungsmodell ein: tokenbasierte API-Preise.
Wenn Sie zwischen einem visuellen Builder wie Bubble und einem KI-nativen Stack entscheiden, müssen Sie verstehen, wie diese Systeme skalieren. Eine App, die in der Testphase fünfzig Dollar im Monat kostet, kann leicht auf hunderte oder tausende Dollar ansteigen, sobald echte Nutzer damit interagieren. Analysieren wir die Kostenentwicklung von Datenbanken, Logik-Triggern und Credits unter beiden Modellen.
Wie Bubble Workload Units tatsächlich funktionieren
Um die Wirtschaftlichkeit von Bubble zu verstehen, muss man sich die Workload Unit ansehen. Eine WU ist eine von Bubble geschaffene Kennzahl, um die Rechenleistung Ihrer App zu quantifizieren. Jedes Mal, wenn Ihre Anwendung eine Aktion auf dem Server ausführt, führt Bubble eine Berechnung durch und zieht WUs von Ihrem Monatstarif ab.
Im Starter-Plan für Einsteiger ($69 pro Monat) erhalten Sie 175.000 WUs. Im Growth-Plan ($249 pro Monat) erhalten Sie 250.000 WUs. Diese Zahlen klingen groß, bis man sieht, wie schnell sie verschwinden.
WUs werden verbraucht durch:
- Datenbankoperationen: Lesen, Schreiben, Ändern oder Löschen von Datensätzen.
- Workflow-Trigger: Ausführen von benutzerdefinierten Aktionen, Bedingungen oder Backend-Workflows.
- API-Connector-Anfragen: Senden von Daten an externe Dienste oder Empfangen von Webhooks.
- Seiten-Overhead: Laden visueller Komponenten und Ausführen initialer Seiten-Workflows.
Das Problem an diesem Modell ist nicht der Preis an sich, sondern die Volatilität. Da Bubbles visuelle Programmiersprache auf deren Servern kompiliert wird, haben Sie keine direkte Kontrolle darüber, wie effizient dieser Code ausgeführt wird. Eine einzige nicht optimierte Suchabfrage kann Ihre gesamte Datenbank scannen und in wenigen Sekunden tausende WUs verbrauchen.
Die Mechanik von KI-API- und Token-Preisen
Auf der anderen Seite der Wirtschaftlichkeitsgleichung steht die tokenbasierte Preisgestaltung. Wenn Sie eine Anwendung mit KI-Codegeneratoren wie Lovable oder Bolt bauen oder benutzerdefinierten Code schreiben, der mit LLMs interagiert, bestimmt die Anzahl der Input- und Output-Token Ihre Abrechnung.
Token sind die Basiseinheiten von Text, die von einer KI verarbeitet werden. Tausend Token entsprechen etwa 750 Wörtern. Das Preismodell hier ist linear und entwicklerzentriert:
- Entwicklungskosten: Sie bezahlen Token, wenn Sie die KI anweisen, den Code Ihrer Anwendung zu schreiben oder zu bearbeiten. Sobald der Code geschrieben ist, läuft er auf Standard-Cloud-Infrastruktur (wie Vercel, Supabase oder Netlify), was bei moderatem Traffic normalerweise kostenlos oder eine Flatrate ist.
- Laufzeit-KI-Kosten: Wenn Ihre App KI-Funktionen nutzt - wie ein Chat-Interface oder automatisierte Dokumentenzusammenfassungen - bezahlen Sie den Modellanbieter (wie Anthropic oder OpenAI) für jede Nutzerinteraktion.
Das bedeutet, dass Ihre Hosting-Kosten niedrig und kalkulierbar bleiben, während Ihre Entwicklungskosten variabel sind. Wenn Ihre Anwendung jedoch in einer automatisierten Schleife läuft oder Sie während der Entwicklung in eine Regressions-Debugging-Schleife geraten, kann Ihr Token-Verbrauch drastisch ansteigen.
Vergleich der Wirtschaftsmodelle
Schauen wir uns an, wie diese Preiskomponenten bei gängigen operativen Aufgaben abschneiden.
| Operative Aufgabe | Bubble Workload Units (WUs) | AI API / Token-Preise |
|---|---|---|
| Datenbankabfragen | Verbraucht WUs pro abgerufenem Datensatz. Große Tabellen oder verschachtelte Suchen führen zu hohem Verbrauch. | Bezahlung über den Datenbank-Host (Flatrate oder speicherbasiert, meist günstig). |
| Business-Logik | Workflows und visuelle Trigger verbrauchen WUs pro Schritt. Scheduler sorgen für einen kontinuierlichen Verbrauch. | Ausführung über Serverless-Funktionen (sehr erschwinglich, oft kostenlos für Millionen von Durchläufen). |
| Externe Integrationen | Der API-Connector verbraucht WUs proportional zur Größe des Payloads. | Standard-API-Gebühren (vernachlässigbare Netzwerkgebühren). |
| AI-Features | Verbraucht WUs für den API-Connector plus direkte Token-Gebühren des AI-Anbieters. | Lineare Abrechnung basierend auf der exakten Anzahl der Input- und Output-Token. |
| App-Wartung | Feste Abonnementkosten für den Editor-Zugriff, keine Kosten für visuelle Updates. | Variable Credit- oder Token-Kosten für AI-Prompts zur Fehlerbehebung und Anpassung. |
Datenbank-Skalierung: Der eigentliche Kostentreiber
Datenbanken sind die häufigste Quelle für böse Überraschungen bei der Abrechnung. In Bubble ist die Optimierung der Datenstruktur zwingend erforderlich. Wenn Sie einen Datentyp namens “Project” erstellen und diesen mit einer Liste von “Tasks” verknüpfen, werden bei einer Projektsuche automatisch die zugehörigen Tasks geladen. Bubble übernimmt dieses relationale Mapping visuell, was für jeden geladenen Datensatz WUs verbraucht. Wenn Sie 5.000 Tasks haben und diese ohne strikte Einschränkungen abfragen, wird Ihr WU-Kontostand schnell sinken.
Im Gegensatz dazu basiert die Skalierung bei einer dedizierten Datenbank wie PostgreSQL oder Supabase auf Rechenressourcen oder der Speicherkapazität. Eine Abfrage, die 10.000 Datensätze durchsucht, benötigt nur wenige Millisekunden CPU-Zeit. Standard-Datenbank-Hoster berechnen den Speicherplatz (z. B. $10 pro Monat für einige Gigabyte), anstatt jeden einzelnen Lese- oder Schreibzugriff abzurechnen.
Logik-Trigger und Workflows: Vorhersehbare vs. variable Kosten
Beim Ausführen von Logik-Triggern wird die Effizienzlücke zwischen proprietären visuellen Plattformen und Standard-Serverless-Infrastrukturen deutlich.
In Bubble läuft jeder Logik-Workflow auf dem Server-Cluster von Bubble. Wenn Sie einen Workflow einrichten, der ausgeführt wird, wenn ein Nutzer einen Button klickt, drei Bedingungen prüft, einen Datensatz aktualisiert und eine E-Mail sendet, kostet jeder dieser Schritte WUs. Wenn Sie einen Backend-Workflow zur Massenverarbeitung von Daten nutzen, werden Schleifen ausgeführt, die Tausende von WUs verbrauchen. Entwickler beschweren sich häufig, dass normale Business-Logik in der Produktion zu teuer im Betrieb ist.
Bei einer AI-generierten App wird Ihre Backend-Logik normalerweise in leichtgewichtigen JavaScript- oder Python-Code kompiliert. Dieser Code läuft auf Serverless-Plattformen, bei denen Sie jeden Monat Millionen von kostenlosen Ausführungs-Millisekunden erhalten. Sie zahlen nichts für das Klicken eines Buttons oder das Auswerten einer “if”-Anweisung. Kosten fallen nur an, wenn Sie während der Ausführung direkte Aufrufe an ein externes AI-Modell tätigen, was linear skaliert.
Die Hybrid-Alternative mit Softr
Wenn Sie eine funktionale Business-App bauen möchten, ohne sich in WU-Berechnungen oder endlosen Prompt-Schleifen zu verlieren, bietet eine Hybrid-Plattform wie Softr eine praktische Lösung.
Softr arbeitet mit einem vorhersehbaren Abonnement-Modell. Sie zahlen einen festen monatlichen Betrag basierend auf dem gewählten Plan (Starter, Basic, Professional oder Business). Dieser Plan gibt Ihnen festgelegte Limits für die Anzahl der App-Nutzer und Datenbankdatensätze, anstatt Sie für jede Suchabfrage oder Seitenaufruf zu berechnen.
Softr löst Datenbank-Skalierung und Logik-Trigger über eine Hybrid-Struktur:
- Native relationale Datenbanken: Softr enthält eine für Geschäftsprozesse optimierte Datenbank. Sie können Datensätze importieren, Beziehungen herstellen und Abfragen ausführen, ohne sich Gedanken über nutzungsbasierte Strafgebühren machen zu müssen.
- AI Co-Builder: Mit dem AI Co-Builder können Sie schnell Seiten, Datenbanken und Workflows generieren. Dies nutzt ein monatliches Credit-Kontingent, ist aber komplett optional. Sie können Ihre gesamte Anwendung visuell im Studio bauen, bearbeiten und warten, ohne Credits zu verbrauchen.
- Isoliertes Vibe Coding: Wenn Sie benutzerdefinierte Komponenten benötigen, können Sie den Vibe Coding Block verwenden, um spezifische Elemente zu generieren, ohne die gesamte Codebasis der Anwendung neu erstellen zu müssen.
Dieser Ansatz kombiniert die Geschwindigkeit der AI-Generierung mit der Kostenvorhersehbarkeit von Flatrate-Hosting. Sie müssen nicht mit plötzlichen Kosten rechnen, nur weil ein Nutzer ein Dashboard geladen oder einen einfachen Logik-Workflow ausgelöst hat.
Praktische Tipps für Builder
Beachten Sie diese Richtlinien bei der Budgetplanung:
- Wählen Sie Flatrate-Optionen für interne Tools mit hohem Traffic: Wenn Ihr Team ständig Tabellen lädt und Datensätze aktualisiert, schützt Sie eine Flatrate-Plattform wie Softr vor WU-Spitzen.
- Optimieren Sie Datenbankabfragen frühzeitig: Wenn Sie auf Bubble bauen müssen, nutzen Sie bei allen Suchen Constraints, um das Laden unnötiger Felder oder Beziehungen zu vermeiden.
- Isolieren Sie Ihre AI-Features: Wenn Sie LLM-Aufrufe integrieren, richten Sie Rate-Limits ein und cachen Sie Antworten, um doppelte Zahlungen für identische Prompts zu vermeiden.
Indem Sie die Architektur Ihrer Anwendung an das richtige Wirtschaftsmodell anpassen, können Sie Tools bauen, die auch bei wachsendem Geschäft erschwinglich bleiben.