Base44 ist eine webbasierte KI-Plattform, die eine Beschreibung in natürlicher Sprache in eine funktionsfähige Anwendung überführt. Der Editor verbindet Chat, Live-Vorschau und Dashboard.
Hast du dieses Tool genutzt? Bewerte es
Hast du dieses Tool genutzt? Bewerte es
Base44 ist eine webbasierte KI-Plattform, die eine Beschreibung in natürlicher Sprache in eine funktionsfähige Anwendung überführt. Der Editor verbindet Chat, Live-Vorschau und Dashboard. Daraus können Seiten, Datenentitäten, Formulare, Zugriffsregeln, Backend-Funktionen, Integrationen und eine veröffentlichte Version entstehen. Die offizielle Entwicklerdokumentation beschreibt Base44 außerdem als verwaltetes Backend, das eine extern entwickelte Oberfläche über JavaScript-SDK und CLI nutzen kann.
Das integrierte Modell spart viel Einrichtungsarbeit, beseitigt aber keine Produktverantwortung. Datenmodell, Berechtigungen, Fehlerpfade, Kosten und Betrieb müssen weiterhin entworfen und geprüft werden. Eine überzeugende Vorschau ist deshalb noch kein Produktionsnachweis. Der sichere Weg führt über einen kleinen vollständigen Ablauf, realistische Daten, Rollentests und eine kontrollierte Veröffentlichung.
Der dokumentierte Quick Start beginnt mit einer Anforderung im KI-Chat, zeigt erzeugte Seiten und Daten in der Vorschau und führt über das Dashboard zur Veröffentlichung unter einer Base44-Adresse. Die Entwicklerunterlagen ergänzen Datenspeicherung, Authentifizierung, Echtzeit-Updates, Funktionen, Integrationen und Hosting. Damit geht das Produkt deutlich über einen statischen Website-Mockup hinaus.
Planrechte, Modelle, Credits und Beta-Funktionen ändern sich jedoch. Ein alter Screenshot oder ein fremder Tarif ist kein belastbarer Beleg für den eigenen Workspace. Diese Darstellung trennt daher aktuelle Dokumentation, angekündigte Roadmap und praktische Empfehlungen. Für eine Kauf- oder Release-Entscheidung gilt immer die aktuelle offizielle Tabelle zusammen mit dem tatsächlich sichtbaren Konto.
Wix gab am 18. Juni 2025 die Übernahme von Base44 bekannt und erklärte, Base44 werde als eigenständiges Produkt und Geschäft weitergeführt. Diese abgeschlossene Transaktion beweist weder die Integration sämtlicher Wix-Dienste noch die Freischaltung einer bestimmten Wix-Funktion in jedem Base44-Konto. Technische Zusagen müssen aus der Base44-Dokumentation oder dem Live-Workspace stammen.
TechCrunch berichtete im Juni 2026 zudem über den beginnenden Rollout des spezialisierten Modells Base1. Ein Rollout ist keine allgemeine Verfügbarkeit. Modellwahl und Credit-Kosten sind im jeweiligen Editor zu prüfen, bevor ein Team Leistung, Latenz oder Budget darauf aufbaut.
Default setzt eine Anforderung in der App um. Discuss dient der Planung, ohne das Projekt zu verändern. Edit ermöglicht gezielte visuelle Änderungen an ausgewählten Elementen. Auch der Credit-Einsatz unterscheidet sich zwischen manueller und KI-gestützter Bearbeitung. Discuss eignet sich deshalb dazu, Schema, Rollen und Risiken vor einer teuren Änderung zu klären.
Eine gute Default-Anweisung nennt Ausgangszustand, betroffene Rolle, Geschäftsregel, erwartetes Ergebnis und ausdrücklich nicht gewünschte Änderungen. Edit ist für Abstände, Typografie, Farbe und einzelne Komponenten sinnvoller als ein breiter Prompt. Die Wahl des Modus ist Teil der Änderungsdisziplin, nicht nur eine Frage der Bedienung.
Base44 stellt persistente Entitäten und eine Oberfläche zur Dateneinsicht bereit. Die Entwicklerdokumentation beschreibt eine flexible NoSQL-Schicht, Echtzeit-Aktualisierungen, Authentifizierung, TypeScript-Funktionen, Integrationen und Hosting. Ein externes Frontend kann diese Dienste über das SDK verwenden.
Vor dem Ausbau der Oberfläche sollte das Datenmodell geprüft werden. Dauerhafte Geschäftskonzepte brauchen klare Entitäten und gültige Zustände. In einer mandantenfähigen App gehört eine Organisationsbeziehung an jeden privaten Datensatz. Ein ausgeblendeter Button ersetzt keine serverseitige Regel, die fremde Datensätze tatsächlich ausschließt.
Der offizielle Ablauf dokumentiert verwaltete Anmeldung, App-Sichtbarkeit, eingeladene Nutzer, Nutzer- und Adminrollen sowie Datenberechtigungen. Mit „act as a user“ lässt sich die Perspektive einer anderen Rolle prüfen. Anmeldung sagt, wer jemand ist; Autorisierung entscheidet, was diese Person lesen oder ändern darf. Beide Ebenen sind getrennt zu testen.
Die aktuelle Login-Dokumentation sagt zugleich, dass ein vollständig eigener Authentifizierungsablauf und vollständig weiß gelabelte integrierte Login-Seiten nicht verfügbar sind; White Labeling wird als geplant beschrieben. Anforderungen an Identity Provider, SSO und Branding müssen daher anhand der aktuellen Unterlagen und des konkreten Tarifs bestätigt werden.
Sensible API-Aufrufe, Webhooks, privilegierte Datenänderungen und Zahlungsprüfungen gehören in eine Backend-Funktion oder verwaltete Integration. Base44 unterscheidet integrierte Aktionen, Connectoren mit verwalteter Autorisierung und Workspace-Integrationen auf Basis importierter OpenAPI-Spezifikationen. Zugangsdaten dürfen nicht in Clientcode, Prompts oder normalen Entitäten landen.
Eine Verbindung ist erst fertig, wenn Ablauf der Autorisierung, Ratenlimit, Pagination, Duplikate und Teilausfälle getestet sind. Halten Sie Eigentümer, Scopes und Wiederanlauf fest. Geld- oder Statusänderungen benötigen Verifikation, Idempotenz und gegebenenfalls eine manuelle Abgleichsliste.
Für Apps, die seit dem 6. Juli 2026 erstellt wurden, ersetzt Workflows laut aktueller Dokumentation Automations. Ältere Projekte können das frühere System behalten; eine App hat eines von beiden. Workflows startet nach Zeitplan, Entitätsänderung, In-App-Agentengespräch oder unterstütztem Connector-Ereignis und kann Bedingungen, Wartezeiten und Aktionen mit Laufanzeige verbinden.
Diese Grenze erklärt, warum ältere Tutorials nicht immer passen. Prüfen Sie zuerst die Oberfläche des Projekts. Definieren Sie dann Trigger, Endzustand und Schutz gegen selbst auslösende Schleifen. Jede externe Nebenwirkung braucht eine Möglichkeit, ein bereits verarbeitetes Ereignis zu erkennen.
Jede App erhält eine Base44-Adresse und kann aus dem Editor veröffentlicht werden. Für berechtigte Tarife sind eigene Domains mit verwaltetem HTTPS dokumentiert. Publishing ersetzt kein Release-Management: Rollen, Scanner, Secrets, Integrationen, Domain und Rückweg müssen vor dem Klick geprüft sein.
Codeansicht, ZIP-Export und die bidirektionale GitHub-Synchronisierung geben berechtigten Teams mehr Kontrolle und ermöglichen lokale Entwicklung, Branches und Pull Requests. Der Export bildet die verwaltete Authentifizierung, Datenbank und das Hosting jedoch nicht als selbst gehostete Infrastruktur nach. Eine echte Migration muss diese Schichten separat ersetzen.
Die Dokumentation nennt mobile Browser sowie iOS- und Android-Builder-Apps. Veröffentlichte Apps laufen mobil im Browser und können dem Startbildschirm hinzugefügt werden. Einzelne Administrationsaufgaben können weiterhin den Desktop erfordern; mobile Bearbeitung sollte deshalb als ergänzende Oberfläche bewertet werden.
Auf einem geeigneten Tarif kann Base44 eine Store-Prüfung durchführen und IPA- beziehungsweise AAB-Pakete erzeugen. Diese sind Web-View-Wrapper der veröffentlichten App, keine unabhängige native Neuentwicklung. Native Push-Nachrichten und vollständiger Offlinebetrieb werden aktuell nicht unterstützt. Entwicklerkonten, Listing, Datenschutzangaben und Einreichung bleiben Aufgabe des Eigentümers.
Ein Gründer kann Anmeldung, Formular, gespeicherte Daten und einen engen Geschäftsablauf testen, bevor eine klassische Stack aufgebaut wird. Die erste Version sollte nur eine Nutzerrolle, ein Kernobjekt und eine messbare Aktion beweisen. Ein Marktplatz kann zunächst eine Seite manuell bedienen; Empfehlungen können mit einer nachvollziehbaren Regel statt sofort mit einem Modell beginnen.
Prüfen Sie, ob ein neuer Nutzer seine Daten nach einer neuen Sitzung wiederfindet, ob eine fremde Rolle ausgeschlossen bleibt und ob ein Fehler den Zustand erhält. Ziel ist Lerngewinn, nicht die sofortige Nachbildung eines reifen Produkts.
Inventar, Freigaben, Onboarding, Incident-Register und Service-Dashboards sind typische begrenzte Prozesse. Entitäten speichern Fälle, Rollen teilen Verantwortung und ein Workflow benachrichtigt oder ändert den Status. Solche Werkzeuge sind oft zu speziell für Standard-SaaS und zunächst zu klein für eine vollständige Eigenentwicklung.
Interne Daten können dennoch personenbezogen, finanziell oder vertraulich sein. Legen Sie fest, ob Base44 System of Record oder Spiegel eines anderen Systems ist, wie Konflikte gelöst werden und wie lange Daten bleiben. Zuständigkeit und Zugriffsregeln gehören zum Produktdesign.
Authentifizierung, Rollen und Datenregeln können ein Portal für Bestellungen, Dokumente oder Anfragen tragen. Jeder private Datensatz braucht Eigentümer oder Tenant. Testen Sie mit Konten zweier Organisationen und versuchen Sie bewusst den Grenzübertritt. Personalisierte Optik ist kein Schutz, wenn die zugrunde liegende Abfrage Daten des Nachbarn liefert.
Auch Entzug von Zugriff, Änderungsprotokoll und Eigentum externer Verbindungen müssen geklärt sein. Fehlertexte sollen helfen, ohne fremde Identitäten oder Systemdetails zu verraten.
Ein neuer Lead kann eine Bestätigung, Wartezeit, Zustandsprüfung und Benachrichtigung auslösen. Ein Kalenderereignis kann eine Buchung aktualisieren; ein Zeitplan kann einen Tagesbericht erstellen. Für jeden Ablauf sind doppelte Ereignisse, erneute Versuche, abgelaufene Verbindungen und ein verständlicher Endzustand einzuplanen.
Filtern Sie irrelevante Events früh, damit sie keine Integrations-Credits verbrauchen. Irreversible oder finanzielle Aktionen brauchen Freigabe oder Abgleich. Ein erfolgreicher Happy Path ist kein Betriebsmodell.
Öffentliche Sites, Landingpages und Rechner lassen sich mit Hosting und Domain verbinden. Base44 ist besonders interessant, wenn zusätzlich Konten, gespeicherte Präferenzen, generierte Ergebnisse oder ein Prozess hinter einem Formular nötig sind. Für rein redaktionelle Sites sollten CMS-Funktionen, SEO, Redirects und Inhaltsgovernance verglichen werden.
Prüfen Sie lange Inhalte, leere Zustände, Formfehler, Tastaturnavigation, Kontrast und schmale Displays. Die Qualität der Startseite sagt wenig über eine große Tabelle oder mehrsprachige Navigation.
Beschreiben Sie Rollen, Datensätze, erlaubte Aktionen und beobachtbares Ergebnis. Nennen Sie Ausschlüsse. Bei Multi-Tenancy muss erklärt sein, wie Organisationen gespeichert und Abfragen begrenzt werden. Nutzen Sie Discuss, um Schema, Zustandsübergänge und Risiken prüfen zu lassen, ohne Änderungen anzuwenden.
Fordern Sie Anmeldung, einen Datensatz, die richtige Rollenansicht und eine bedeutsame Aktion. Prüfen Sie Entität, Felder, Validierung, Refresh und neue Sitzung. Reparieren Sie das Modell, bevor weitere Dashboards und Integrationen davon abhängen.
Testen Sie create, read, update und delete pro Rolle. Verschieben Sie Zugangsdaten in Secrets und sensible Aufrufe auf den Server. Führen Sie den Security Scanner aus, lesen Sie jede Empfehlung und versuchen Sie mit Testkonten auch verbotene Zugriffe. Der Scanner übernimmt nicht automatisch jede Korrektur.
Verbinden Sie einen Dienst, prüfen Sie Konto und Scopes, testen Sie Erfolg und Fehler sowie mehrere Seiten und Duplikate. Schreiben Sie beim Workflow Trigger, Bedingungen, Wartezeiten und Endzustand vor den Aktionen auf. Kleine Änderungen lassen sich besser zurücknehmen und verursachen weniger unnötige Credits.
Verwenden Sie lange Namen, leere optionale Felder, Sonderzeichen und Grenzwerte. Prüfen Sie jede Rolle in einer echten Browser-Sitzung und mobil. Store-Wrapper spiegeln die Web-App; daher ist zuerst der veröffentlichte Webablauf zu validieren.
Exportieren Sie wichtige Daten und Code, sichern Sie die geprüfte Version, notieren Sie Tarif und Verbindungen und kontrollieren Sie Scanner und Domain. Testen Sie nach dem Release als neuer Nutzer. Beobachten Sie Funktionen, Workflow-Läufe und Credit-Verbrauch und machen Sie aus Feedback kleine überprüfbare Änderungen.
„Freigabeseite hinzufügen“ ist unklar. Eine prüfbare Regel benennt Rolle, Zustand, Tenant, Ergebnis, Akteur und Zeit. Trennen Sie Funktion und Gestaltung, damit eine optische Änderung keine Datenlogik verdeckt.
Kombinieren Sie nicht Authentifizierung, Schema, Zahlung und Redesign. Führen Sie außerhalb des Chats ein Änderungsprotokoll mit Anforderung, Prompt, betroffenen Entitäten, Testergebnis und Release. Chatverlauf ist Kontext, keine dauerhafte Spezifikation.
Nachrichten- und Integrations-Credits sind getrennt. Modell, Komplexität, Zeitpläne und externe Aufrufe bestimmen den Verbrauch. Planen Sie in Discuss, filtern Sie laute Trigger und messen Sie den echten Ablauf während eines Trials statt nur den ersten Build.
Dokumentieren Sie Daten, Funktionen, Secrets, Domains und Auth-Annahmen. Probieren Sie Export und Wiederherstellung. Trennen Sie eine Integration, senden Sie ein doppeltes Ereignis und erzwingen Sie einen Fehler. Nutzer brauchen eine verständliche Meldung, Betreiber einen Weg zum Fortsetzen oder Abgleichen.
Nichttechnische Gründer profitieren, wenn sie Rollen und Kriterien definieren können, aber keine Infrastruktur montieren wollen. Produktmanager und Designer bauen funktionale Prototypen mit echten Daten. Operations-Teams bilden begrenzte, organisationsspezifische Prozesse ab.
Entwickler können Code, GitHub, CLI, SDK und Managed Backend nutzen; Agenturen können Portale und Dashboards liefern, wenn Eigentum, Kosten und Übergabe geregelt sind. Weniger passend ist Base44 bei zwingendem Self-Hosting, vollständigem Offlinebetrieb, tief nativer Mobile-Logik, speziellen Datenbankgarantien oder unabhängig geprüften regulierten Kontrollen.
Editor, Preview und veröffentlichte Apps sind webbasiert. Mobile Browser und Builder-Apps für iOS und Android sind dokumentiert; bestimmte Verwaltungsaufgaben können Desktop erfordern. Ein externes Frontend kann per SDK auf das verwaltete Backend zugreifen.
Eigene Domains, ZIP und GitHub hängen vom Tarif ab. Store-Pakete sind Web-Wrapper und setzen eigene Apple- beziehungsweise Google-Konten voraus. Jede benötigte Berechtigung ist vor einer vertraglichen Zusage in der aktuellen Plantabelle zu prüfen.
Die geprüfte offizielle Dokumentation listet Free, Starter, Builder, Pro und Elite und zeigt eine Vergleichstabelle. Da Rechte unabhängig von Namen wechseln können, ordnet dieser Text keinem Tarif dauerhaft Funktionen zu. Prüfen Sie App-Limits, Credits und jede Produktionsanforderung in der aktuellen Tabelle und im Konto.
KI-Nachrichten und Integrationsaktionen haben getrennte Kontingente. Aufwand und Modell beeinflussen Nachrichten, externe Aktionen und Workflows das Integrationsbudget. Kalkulieren Sie Iteration, geplante Läufe und Wartung. Aktuelle Preise und Abrechnungsperioden gehören vor dem Kauf erneut geprüft.
Lovable und Bolt sind promptorientierte Web-Builder. Replit verbindet Coding-Agent, Entwicklungsumgebung und Deployment. Softr fokussiert strukturierte Business-Apps. Retool und Power Apps bieten reife interne Connectoren und Governance. Konventionelle Entwicklung liefert maximale Infrastrukturkontrolle bei höherem Aufwand.
Vergleichen Sie denselben vollständigen Ablauf: Backend, Rollen, Git, Design, Fehler, Export und Migration. Eine spektakuläre Demo beantwortet nicht, welche Option nach Monaten leichter zu betreiben ist.
Die geprüften Product-Hunt- und G2-Seiten enthalten positive und negative Erfahrungen, ihre Teilnehmer wählen sich jedoch selbst aus. G2 zeigte vier Reviews, Capterra drei; beide Stichproben sind zu klein für allgemeine Qualitätsurteile. Nutzen Sie Themen daraus nur für einen repräsentativen Trial.
Der Scanner prüft Berechtigungslücken, offengelegte Zugangsdaten, Login-Verifikation, verwundbare Pakete und Browser-Header. Base44 weist dem App-Eigentümer die Prüfung und Entscheidung zu. Die Privacy-Dokumentation nennt US-Speicherung als Standard und tarif- beziehungsweise erstellungsabhängige EU/UK-Optionen; sie rechtfertigt keine erfundene Zertifizierung oder Verschlüsselungszusage.
Code und Daten können je nach Tarif exportiert werden, Managed Auth, Datenbank und Hosting werden aber nicht zu Self-Hosted-Komponenten. Store-Wrapper haben derzeit kein natives Push und keinen vollständigen Offlinebetrieb. Geplante Abrechnung oder White-Label-Authentifizierung darf erst nach aktueller Bestätigung versprochen werden.
Ja. Die Dokumentation umfasst Oberfläche, Daten, Authentifizierung, Funktionen, Integrationen, Workflows und Hosting. Produktionsreife entsteht erst durch Modellierung, Rechte, Tests und Betrieb.
Für eine einfache Chat- und Visual-Edit-App nicht. Für Schema, Sicherheit, komplexe Funktionen und Migration ist technisches Wissen wertvoll; Code, GitHub, CLI und SDK stehen Entwicklern zur Verfügung.
Dokumentiert sind Free sowie Starter, Builder, Pro und Elite. Funktionen, Credits und Limits müssen in der aktuellen Tabelle geprüft werden.
Message-Credits decken KI-Bauinteraktionen ab, Integrations-Credits externe und automatisierte Aktionen. Der Verbrauch hängt von Aktion, Modell und Komplexität ab.
ZIP, GitHub und Datenexport sind auf berechtigten Tarifen dokumentiert. Sie reproduzieren Auth, Datenbank und Hosting nicht automatisch; eine vollständige Migration braucht einen Architekturplan.
Base44 kann auf einem geeigneten Tarif Pakete erzeugen. Eigentümer stellen Entwicklerkonten und verwalten Review und Listings. Der Wrapper bietet kein natives Push und keinen vollen Offlinebetrieb.
Setzen Sie Sichtbarkeit und Datenrechte, schützen Sie Secrets, führen Sie den Scanner aus und testen Sie jede Rolle mit getrennten Konten. Hochriskante Apps brauchen zusätzliche unabhängige Prüfung.
Beides ist auf berechtigten Tarifen dokumentiert. Domains erhalten verwaltetes HTTPS, GitHub bidirektionale Synchronisierung. Live-Rechte und Repository-Eigentum sind zu bestätigen.
Es sind zwei Generationen. Seit 6. Juli 2026 erstellte Apps nutzen laut Dokumentation Workflows; ältere können Automations behalten. Eine App zeigt nur eines der Systeme.
Ja, wenn Managed Runtime passt und Rechte, Zuverlässigkeit, Kosten, Portabilität und Support im repräsentativen Pilot geprüft werden. Bei zwingender Infrastrukturhoheit oder tief nativen beziehungsweise regulierten Anforderungen ist eine kontrollierbarere Stack sinnvoller.
