Es gibt zwei Wege, eine Tabelle in eine App umzuwandeln. Der erste behält die Tabelle als Datenbank und setzt eine Anwendung darauf: Glide, AppSheet und Softr schaffen das an einem Nachmittag, und jede Änderung in der App landet in einer Zelle. Der zweite verschiebt die Daten in eine echte Datenbank und generiert die Anwendung darauf: Das dauert ein bis zwei Tage, dafür bekommen Sie Rollen, einen Änderungsverlauf und keine Zeilengrenze. Die Faustregel ist einfach. Behalten Sie die Tabelle, wenn ein Team sie nutzt, überwiegend zum Lesen, und sie ein paar tausend Zeilen enthält. Wechseln Sie die Daten, wenn mehrere Personen täglich hineinschreiben, wenn manche nicht alles sehen dürfen oder wenn die Datei unbemerkt zum führenden System des Unternehmens geworden ist.
Dieser Leitfaden behandelt beide Wege: die Grenzen, die den Wechsel nötig machen, die Vorbereitung der Datei, die bei jedem Weg den Großteil der Arbeit ausmacht, eine Methode in fünf Schritten und die Tools im Vergleich nach Preis, Zeilenobergrenze und dem, was Ihnen am Ende gehört. Er gilt für Excel und Google Sheets gleichermaßen und für den CSV-Export fast jedes anderen Systems.
Zwei Wege, eine Tabelle in eine App umzuwandeln
Hinter „Tabelle in App“ stecken zwei sehr verschiedene Vorgänge. Beim ersten bewegt sich nichts: Ein Tool verbindet sich mit Ihrem Google-Sheets- oder Excel-Dokument, liest die Zeilen und zeigt sie als Listen, Formulare und Detailseiten auf dem Handy oder im Browser. Beim zweiten werden die Zeilen einmal in eine Datenbank importiert, die Tabelle wird archiviert, und die Anwendung besitzt die Daten fortan.
| Weg | So funktioniert er | Erste Version | Die Tabelle wird zu | Am besten für |
|---|---|---|---|---|
| Eine App auf der Tabelle (Glide, AppSheet, Softr) | Das Tool liest und schreibt die Zeilen der Tabelle; jede Spalte wird zu einem Feld | Stunden | Weiterhin der Datenbank | Formulare, Listen und Nachschlagen für ein kleines Team; Dateneingabe im Außendienst |
| Eine Datenbank und eine generierte App (Cadrant oder Low-Code auf PostgreSQL) | Die Zeilen werden in Tabellen mit Relationen importiert; Screens und Rollen werden generiert | Ein bis zwei Tage | Einem Archiv | Mehrbenutzer-Tools mit Rollen, Regeln und Verlauf |
Wann eine Tabelle nicht mehr reicht
Die technischen Grenzen sind großzügig und selten das eigentliche Problem. Ein Excel-Arbeitsblatt fasst 1.048.576 Zeilen mal 16.384 Spalten, und eine Google-Sheets-Datei bis zu 20 Millionen Zellen. Die Grenzen, an die Sie zuerst stoßen, sind menschliche.
| Grenze | Tabelle | Anwendung auf einer Datenbank |
|---|---|---|
| Größe | Excel: 1.048.576 Zeilen pro Blatt. Google Sheets: 20 Millionen Zellen. Altes XLS: 65.536 Zeilen | Millionen Zeilen pro Tabelle ohne Produktgrenze |
| Mehrere Personen schreiben | Der letzte Speichervorgang gewinnt, oder es entsteht eine Konfliktkopie | Jede Zeile wird einzeln gespeichert; nichts wird überschrieben |
| Wer was sieht | Ausgeblendete Blätter und geschützte Bereiche, leicht zu umgehen | Rollen, in der Datenbank erzwungen, Zeile für Zeile |
| Wer was geändert hat | Versionsverlauf der Datei, nicht des Datensatzes | Ein Protokoll pro Datensatz, mit Autor und Zeitpunkt |
| Regeln | Formeln und Datenüberprüfung, von jedem Bearbeiter löschbar | Validierungen und Constraints, die niemand umgehen kann |
Das leisere Problem ist der Fehler. Die Auswertung von Praxisprüfungen durch Ray Panko an der University of Hawaii fand in 88 % der 113 seit 1995 geprüften operativen Tabellen Fehler, die meisten in Formeln, die niemand kontrolliert hatte. Zeigt Ihre Datei zwei oder mehr der fünf Signale aus unserem Leitfaden, wie Sie interne Tools erstellen, also mehrere Bearbeiter, ausgeblendete Zeilen, ein Blatt, das niemand anzufassen wagt, kein Verlauf, neu eingetippte Daten, dann sollten Sie den zweiten Weg einplanen.
Die Datei vorbereiten: von Spalten zu Tabellen
Welches Tool Sie auch wählen, es liest Ihre Datei immer gleich: eine Kopfzeile, ein Datensatz pro Zeile, ein Wert pro Zelle. Die meisten Tabellen, die über Jahre gewachsen sind, brechen irgendwo alle drei Regeln. Eine Stunde Aufräumen vor dem Import spart einen Tag Korrekturen danach.
Dann folgt der Schritt, der aus einer Tabelle ein Datenmodell macht. Suchen Sie nach Werten, die sich wiederholen: ein Kundenname, der in vierzig Bestellzeilen steht, ein Produkt samt Preis, das in jede Zeile kopiert wurde. Jedes wiederholte Ding wird zu einer eigenen Tabelle mit einer ID, und die ursprüngliche Zeile behält nur die ID. Das nennt man Normalisierung, und es ist der Unterschied zwischen einer Datei und einer Datenbank.
Über jede Formel sollten Sie einzeln entscheiden. Eine Spalte, die aus Menge und Preis eine Summe berechnet, wird zu einem berechneten Feld. Eine Spalte, die verspätete Bestellungen markiert, wird zu einer Regel in der Anwendung. Ein Pivot-Blatt, das den Umsatz nach Monat zusammenfasst, wird zu einem Dashboard-Screen, generiert aus der Bestelltabelle. Keine davon wird als Daten importiert.
Die App in fünf Schritten bauen
- 1. Die Datei einfrieren und exportieren. Kündigen Sie einen Stichtag an, setzen Sie die Tabelle auf schreibgeschützt und exportieren Sie pro Blatt eine CSV-Datei. Beim ersten Weg verbinden Sie stattdessen hier das Tool mit der Tabelle.
- 2. Die Tabellen anlegen und die Zeilen importieren. Importieren Sie zuerst die Referenztabellen (Kunden, Produkte), dann die Tabellen, die darauf verweisen (Bestellungen). Vergleichen Sie die Zeilenzahlen mit der Tabelle, bevor Sie weitermachen.
- 3. Die Screens generieren. Eine Liste, eine Detailseite, ein Formular und ein Statuswechsel für jede Haupttabelle. In der ersten Version nicht mehr: keine Berichte, keine Benachrichtigungen.
- 4. Die Regeln neu aufbauen. Aus der Datenüberprüfung werden Pflichtfelder und erlaubte Werte. Aus Formeln werden berechnete Felder. Aus dem Farbcode werden Status. Schreiben Sie die Rollenmatrix: Wer darf in jeder Tabelle sehen, anlegen, bearbeiten und löschen?
- 5. Eine Woche beides parallel betreiben. Drei echte Nutzer, echte Daten, die eingefrorene Tabelle daneben. Sammeln Sie jede Beschwerde in einer Liste, korrigieren Sie das Datenmodell einmal und schaffen Sie dann die Datei ab.
Bei Cadrant sind die Schritte 2 bis 4 das, was die Plattform aus dieser Beschreibung generiert. Sie erzeugt eine React-Anwendung, die mit einer PostgreSQL-Datenbank in Ihrem eigenen Supabase-Projekt verbunden ist, mit Tabellen, Relationen und Indizes aus der Beschreibung, und Login-Seiten über Supabase Auth mit den Rollen, die Sie genannt haben. Die Zeilen importieren Sie per CSV im Supabase-Dashboard, das Sie im Bereich Datenbank des Projekts öffnen können, und die Row-Level-Security-Richtlinien, die erzwingen, wer was sieht, werden aus dem Prompt in der Datenbank angelegt; die Dokumentation empfiehlt, sie vor dem Produktivbetrieb zu prüfen. Der Starter-Tarif kostet 20 $ im Monat, egal wie viele Kolleginnen und Kollegen das Tool nutzen, und ab dem Pro-Tarif (40 $ im Monat) wird der Code mit einem GitHub-Repository synchronisiert. Die Details stehen auf der Seite zum Baukasten für interne Tools.
Welches Tool für welche Tabelle
Die Preise sind die öffentlichen Listenpreise im September 2026, bei jährlicher Abrechnung, wo es eine Wahl gibt. Cadrant steht an erster Stelle, weil es unser eigenes Produkt ist und das einzige unten, das den zweiten Weg geht; die drei anderen sind die Referenztools für den ersten Weg, und für ein kleines, überwiegend lesendes Team sind sie die schnellere Antwort.
| Tool | Ansatz | Preise | Zeilenobergrenze | Was Ihnen gehört | Am besten für |
|---|---|---|---|---|---|
| Cadrant | Import in PostgreSQL, App aus einer Beschreibung generieren | Pauschal, ab 20 $ im Monat, keine Nutzerlizenzen | Keine durch das Produkt | Datenbank auf Ihrem Supabase, Code auf GitHub (Pro-Tarif) | Mehrbenutzer-Tools mit Rollen und Regeln |
| Glide | App auf Sheets, Excel oder eigenen Tabellen | 19 bis 199 $ im Monat; Business-Nutzer ab dem 31. für je 5 $; Updates werden gezählt | 25.000 Zeilen pro App auf einer Tabelle | Die Tabelle; die App bleibt bei Glide | Ansprechende Mobile-Apps für ein kleines Team |
| AppSheet | App auf Sheets, Excel oder einer Datenbank | 5 bis 20 $ pro Nutzer und Monat; Core in den meisten kostenpflichtigen Google-Workspace-Tarifen enthalten | Die der Quelle, mit Synchronisierungsgrenzen | Die Tabelle; die App bleibt bei AppSheet | Dateneingabe im Außendienst in einem Google-Workspace-Unternehmen |
| Softr | Portale auf Airtable, Sheets oder SQL | 25, 119 oder 395 $ im Monat mit Nutzerkontingenten | Die der Quelle | Die Quelle; die App bleibt bei Softr | Kundenportale auf Daten, die Sie anderswo halten |
Liegen Ihre Daten schon in Airtable statt in einer Tabelle, gilt dieselbe Überlegung mit einer Variablen mehr, der Rechnung pro Lizenz; unser Leitfaden zu den Airtable-Alternativen behandelt diesen Fall.
- Zwei Wege: eine App auf der Tabelle in Stunden, oder die Daten in eine Datenbank verschieben und die App in ein bis zwei Tagen generieren.
- Tabellen scheitern an den Menschen, bevor sie an der Größe scheitern: gleichzeitige Änderungen, keine Rollen, kein Verlauf, Regeln, die jeder löschen kann.
- Die Vorbereitung ist der Großteil der Arbeit: eine Kopfzeile, ein Wert pro Zelle, eine ID pro Zeile, wiederholte Werte in eigenen Tabellen.
- Zuerst die Referenzen importieren, die kleinsten Screens generieren, die Regeln neu aufbauen, eine Woche beides parallel betreiben.