Zugo vs. Softr: Portal über Airtable oder eigenes Projekt?
Zugo vs. Softr: Portal über Airtable oder eigenes Projekt?
Softr setzt Kundenportale und interne Werkzeuge aus Bausteinen zusammen, meist über Daten, die bereits in Airtable liegen. Zugo erzeugt aus einer Beschreibung den Code für eine Website, eine App oder ein 2D-Spiel und veröffentlicht ihn unter einer Adresse wie ihr-projekt.zugo.run. Softr passt zu vorhandenen Daten, Zugo zu eigenem Code.
Wir bauen Zugo, das hier ist also keine unparteiische Bewertung, sondern der Versuch einer sauberen. Wer bei einem Vorhaben von Softr weggelotst wird, das dort besser aufgehoben ist, verliert eine Woche, und wir verlieren sein Vertrauen dauerhaft.
Was entsteht bei Softr, was bei Zugo?
Softr baut eine Anwendung aus Bausteinen: Listenansichten, Detailseiten, Formulare, Diagramme, Benutzerkonten, Sichtbarkeitsregeln. Die Daten selbst liegen woanders, sehr oft in Airtable, und Softr stellt sie dar und schirmt sie ab. Sie konfigurieren, statt zu schreiben, und das Ergebnis läuft auf der Plattform des Anbieters.
Zugo erzeugt das Projekt selbst. Sie beschreiben in normaler Sprache, was entstehen soll, und bekommen echten Code für eine Website, eine App, eine mehrseitige Plattform oder ein 2D-Browserspiel. Vor der Übergabe startet jeder Build in einer Sandbox: Was nicht geöffnet hat, wird als Fehlschlag gemeldet und nicht ausgeliefert.
Dieser eine Unterschied erklärt fast alles Weitere. Softr ist eine Darstellungsschicht über einer Datenbasis, die Sie ohnehin pflegen. Zugo ist ein Generator, deshalb ist die Datenbank ein Anschluss über Supabase und nicht die Achse, um die sich das Produkt dreht.
Wo gewinnt Softr?
An vier Stellen, die im Marketing eines Builders üblicherweise fehlen.
Airtable als führendes System. Wenn Ihr Tagesgeschäft in Airtable-Basen läuft, die täglich gepflegt werden, trifft Softr diese Wirklichkeit dort, wo sie ist. Nichts muss umziehen, und die Tabelle, der Ihr Team vertraut, bleibt die Tabelle, der Ihr Team vertraut.
Portale mit Sicht auf eigene Zeilen. Kundenportale, Mitgliederbereiche und interne Werkzeuge, in denen jede Person nur ihre eigenen Datensätze sieht, sind die Form, für die Softr entworfen wurde. Das Rechtemodell gehört zum Produkt und ist nicht etwas, das Sie beschreiben und dann hoffen.
Ändern ohne Prompt. Nach dem Start heißt eine Änderung, einen Baustein zu verschieben. Für ein Team ohne technischen Hintergrund, das wöchentlich an der Anwendung arbeitet, ist das ein anderer Alltag als eine erneute Beschreibung.
Bekannte Formen, fertig gelöst. Verzeichnisse, Stellenbörsen, Mitgliederbereiche und Übersichtsseiten liegen als Bausteine und Vorlagen bereit. Wenn Ihr Vorhaben eine dieser Formen hat, schlägt Konfigurieren das Erzeugen.
Was macht Zugo anders?
Das Ergebnis ist Code, der Ihnen gehört. Der GitHub-Export liefert ein echtes Repository, der Vercel-Anschluss den Betrieb im eigenen Konto. Zugo zu verlassen heißt, das Projekt mitzunehmen, statt es neu zu bauen.
Die Bandbreite reicht weiter als Portale. Websites, Landingpages, mehrseitige Plattformen und 2D-Browserspiele sind reguläre Ergebnisse. 25 Vorlagen gehören zum Produkt, davon 5 für Spiele.
Die Prüfung vor der Übergabe. Ein Build, der nicht geöffnet hat, erreicht Sie nicht. Das ersetzt keine inhaltliche Prüfung, verhindert aber die häufigste Enttäuschung mit erzeugtem Code.
Preise je Aktion, vorher bekannt. Eine Änderung kostet 3 Credits, ein frischer Build 6, eine mehrseitige Plattform 12 für die ersten drei Seiten und danach 3 je weiterer Seite. Die Abrechnung hängt nicht daran, wie viele Menschen die Anwendung später benutzen.
Wie sieht der Vergleich Punkt für Punkt aus?
| Zugo | Softr | |
|---|---|---|
| Ausgangspunkt | eine geschriebene Beschreibung | eine vorhandene Datenbasis |
| Ergebnis | Code für Website, App oder 2D-Spiel | Anwendung auf der Plattform des Anbieters |
| Daten | Anschluss an Supabase | Airtable und ähnliche Quellen |
| Ändern nach dem Start | beschrieben, 3 Credits je Änderung | Bausteine im Editor anpassen |
| Sicht je Person auf eigene Zeilen | über Regeln in der Datenbank | Teil des Produktmodells |
| Öffentliche Website | eigener Build-Typ | möglich, nicht der Schwerpunkt |
| 2D-Spiele | eigener Build-Typ, 5 Vorlagen | kein Einsatzzweck |
| Zahlungen | Anschluss an Stripe | über die dortigen Integrationen |
| Mailversand | Anschluss an Resend | über die dortigen Integrationen |
| Code-Export | GitHub-Export, das Projekt gehört Ihnen | kein Produkt für Code-Export |
| Betrieb im eigenen Konto | Vercel-Anschluss | nicht vorgesehen |
| Veröffentlichung | ihr-projekt.zugo.run, eigene Domain möglich | Hosting des Anbieters |
| Prüfung vor Übergabe | Start in der Sandbox, Fehlschlag wird gemeldet | Vorschau während der Konfiguration |
| Abrechnung | feste Credits je Aktion | siehe Preisseite des Anbieters |
Wir nennen belastbar nur unsere eigenen Zahlen. Tarife, Grenzen und enthaltene Bausteine ändern sich bei jedem Anbieter, deshalb gehört die rechte Spalte auf deren Preisseite geprüft.
Was kostet die Zugo-Seite?
| Aktion | Credits | Im Hi-Fi-Modus |
|---|---|---|
| Build: Website, App oder Spiel | 6 | 12 |
| Änderung an einem bestehenden Projekt | 3 | 6 |
| Mehrseitige Plattform, erste drei Seiten | 12 | doppelt |
| Jede weitere Seite | 3 | 6 |
Free enthält 5 Credits, also weniger als die 6 für einen frischen Build. Pro kostet 25 $ im Monat mit 200 Credits, das entspricht etwa 16 mehrseitigen Plattformen oder 33 Builds oder 66 Änderungen. Business kostet 99 $ im Monat mit 800 Credits, abgerechnet in US-Dollar.
Der strukturelle Punkt ist wichtiger als die Summen. Plattformen, die Ihre laufende Anwendung betreiben, rechnen üblicherweise nach Plätzen, Personen oder Datensätzen ab, die Kosten wachsen also mit dem Erfolg. Zugo rechnet das Erzeugen und Ändern ab: Ein Portal mit fünfzig Zugängen kostet im Betrieb dasselbe wie eines mit fünf. Die Rechnung dazu steht in CRM mit KI bauen.
Welches Vorhaben gehört wohin?
| Vorhaben | Bessere Wahl | Grund |
|---|---|---|
| Kundenportal über bestehenden Airtable-Basen | Softr | trifft die Daten dort, wo sie liegen |
| Öffentliche Firmenseite oder Landingpage | Zugo | Websites sind ein eigener Build-Typ |
| Mitgliederbereich mit Sicht auf eigene Zeilen | Softr | Rechtemodell gehört zum Produkt |
| 2D-Browserspiel | Zugo | eigener Build-Typ, 5 Spielvorlagen |
| Produkt, das Sie verkaufen wollen | Zugo | Stripe-Anschluss und Code zum Mitnehmen |
| Internes Werkzeug, wöchentlich angepasst | Softr | Bausteine schlagen erneutes Beschreiben |
| Vorhaben ohne bestehende Datenbasis | Zugo | es gibt nichts, wozu ein Portal passen müsste |
| Projekt, das später jemand übernimmt | Zugo | GitHub-Export übergibt ein Repository |
Wenn Sie in der Mitte landen, entscheidet die Frage, wer die Daten pflegt. Werden sie von Hand in einer geteilten Basis gepflegt, ziehen die Gewohnheiten Richtung Softr, und dagegen gewinnt kein Werkzeug.
Wie sieht ein Kundenportal in Zugo aus?
Es entsteht als Projekt mit angeschlossener Datenbank. Supabase liefert Tabellen, Anmeldung und Dateiablage, und die Regeln, wer welche Zeilen sieht, werden dort hinterlegt. Das funktioniert und verlangt eine Entscheidung mehr von Ihnen, als ein Modell, in dem Rechte bereits Teil des Produkts sind.
Der Vorteil dieses Wegs zeigt sich später. Die Oberfläche ist nicht an einen Baustein-Katalog gebunden, ein zusätzlicher Bereich ist eine Änderung und keine Frage danach, ob es dafür einen Baustein gibt. Und die Datenbank gehört zu Ihrem Konto, nicht zur Plattform, auf der das Portal läuft.
Für den Einstieg lohnt der Blick auf Kann KI eine Datenbank-App bauen und auf Kann KI eine Anmeldung bauen. Beide beschreiben, wo die Arbeit tatsächlich anfällt, nämlich beim Nachdenken über die Daten und nicht beim Tippen.
Welche Grenzen hat Zugo?
Vier, unbeschönigt. Es gibt keinen Anschluss an Airtable oder eine Tabellenkalkulation. Die Anschlüsse sind Supabase, Stripe, GitHub, Vercel, Resend, Google Analytics und die eigene Domain. Wenn Ihr Betrieb an einer bestehenden Basis hängt, ist das eine echte Lücke.
Bei einem wirklich komplexen Produkt ersetzt Zugo kein Entwicklungsteam. Sie bekommen eine lauffähige erste Fassung, keine Entwicklungsabteilung, und der Abstand wächst mit dem Umfang.
Sehr spezifische Fachlogik entsteht über mehrere Änderungen. Eine ungewöhnliche Freigaberegel oder ein Sonderfall in der Abrechnung übersteht selten einen einzigen Prompt.
Und Spiele sind 2D und laufen im Browser. Das gehört in jede ehrliche Aufzählung, auch wenn es in einem Portal-Vergleich selten den Ausschlag gibt.
Wie entscheide ich?
Beantworten Sie zuerst, wo Ihre Datensätze in einem Jahr liegen sollen. Lautet die Antwort Airtable, weil Kolleginnen dort täglich arbeiten, ist die Sache entschieden, und keine Vergleichstabelle hebt das auf.
Lautet die Antwort, dass es noch keine Daten gibt oder dass eine richtige Datenbank her soll, verschiebt sich die Frage darauf, was Sie am Ende besitzen wollen. Eine konfigurierte Anwendung ist schneller eingerichtet und bleibt in der Plattform. Erzeugter Code kostet eine Beschreibung und hinterlässt Ihnen ein Repository.
Am schnellsten klären Sie das praktisch: Beschreiben Sie das gewünschte Werkzeug mit den Startguthaben auf zugo.dev, bauen Sie die Entsprechung in Softr, und behalten Sie das Ergebnis, das Sie einer neuen Kollegin am Montag ohne Einweisung geben würden.