AppSheet kostet 5–20 $ pro Nutzer und Monat — aber das größere Problem ist unsichtbar: Die reine Klick-Konfiguration kann kein KI-Agent bedienen. Echte Kostenrechnung und der Weg zu Config-as-Code.

Kurzfassung

Frage	Kurze Antwort
Was kostet AppSheet bei realer Teamgröße?	15 Nutzer auf Core ≈ 150 $/Monat (1.800 $/Jahr); 25 Nutzer auf Enterprise Plus ≈ 500 $/Monat (6.000 $/Jahr)
Ist das Pro-Sitz-Modell das eigentliche Problem?	Nein — bei 10 Nutzern tragbar, ab 25+ schmerzhaft
Welches Problem preist niemand ein?	Jede Änderung ist manuelle Klickarbeit — kein Config-as-Code, also kann kein KI-Agent Ihre App für Sie bedienen
Wann ist AppSheet weiterhin richtig?	≤10 Nutzer, Standard-Workflow, jemand intern pflegt die App gern

AppSheets Preise sind öffentlich und simpel: Starter 5 $, Core 10 $, Enterprise Plus 20 $ pro Nutzer und Monat (Preise, August 2026), mit kostenlosem Prototyping für bis zu 10 Nutzer. Aber zwei Kosten tauchen nie im Abo-Vergleich auf: das Sitzkriechen, während das Team wächst, und der Wartungs-Flaschenhals, der 2026 auftauchte — dem Jahr, in dem fast jede andere Softwareart KI-wartbar wurde. Außer Ihrer.

(Eine Nuance vor der Rechnung: Wenn Sie eine kostenpflichtige Google-Workspace-Edition nutzen, prüfen Sie welche Editionen AppSheet Core einschließen — manche bündeln es. Das verändert die Rechnung für die Nutzer Ihres Teams mit solchen Lizenzen.)

Die Sitz-Rechnung, ehrlich durchgeführt

Team	Realistisch nötiger Tarif	Monatlich	Pro Jahr	Über 3 Jahre
5 Nutzer	Starter	25 $	300 $	900 $
10 Nutzer	Core	100 $	1.200 $	3.600 $
15 Nutzer	Core	150 $	1.800 $	5.400 $
25 Nutzer	Enterprise Plus	500 $	6.000 $	18.000 $
40 Nutzer	Enterprise Plus	800 $	9.600 $	28.800 $

Zwei Dinge verstecken sich in dieser Tabelle:

• Sie bleiben selten bei Starter. Dort fehlen Sicherheitskontrollen und App-Verwaltung — sobald Rollen oder Datenverantwortung zählen, sind Sie bei Core.
• APIs und echte Datenbanken sind Enterprise-Plus-Territorium. AppSheet mit PostgreSQL oder externen Diensten zu verbinden, liegt im 20-$-Tarif. Wenn Ihre Daten Sheets sprengen (der Grund, warum Sie das hier lesen), ist das der Tarif, auf den Sie zusteuern.

Mit 25 Nutzern zahlen Sie 18.000 $ über drei Jahre für das Recht, die Plattform zu nutzen — bevor irgendjemandes Zeit eingerechnet ist. Und jemandes Zeit ist der nächste Kostenpunkt.

Das 2026-Problem: Ihre App kann von keinem Agenten bedient werden

Das hat sich kürzlich geändert, und es wiegt schwerer als die Sitz-Rechnung.

Fast jede andere Form von Business-Software wurde agenten-wartbar: Wenn Ihr System eine normale Codebasis ist, können Sie einem KI-Agenten sagen: „Ändere die Freigaberegel für Rabatte so, dass über 500 $ die Managerfreigabe nötig ist” — und der Agent liest den Code, nimmt eine kleine, reviewbare Änderung vor und aktualisiert die Tests. Minuten Arbeit, kein angestellter Entwickler nötig.

AppSheet hat keinen entsprechenden Weg. Seine Konfiguration — Tabellen, Slices, Bots, Verhalten, Sicherheitsfilter, virtuelle Spalten — lebt in einem Web-Editor, den man per Klick bedient. Es gibt kein Config-as-Code, kein CLI, keine API, um die Anwendung selbst zu verändern. Wenn Sie also einer KI bitten, Ihre AppSheet-App zu ändern, lautet die ehrliche Antwort: Sie kann es nicht. Ein Mensch muss den Editor öffnen, unter Dutzenden die richtige Oberfläche finden, den Ausdruck bearbeiten, speichern und auf einem Gerät testen. Multiplizieren Sie das mit jeder Änderungsanfrage, die Ihr Unternehmen erzeugt.

Das Ergebnis ist das Muster, das ich immer wieder vorfinde: ein Office Manager, der „die App kennt” und still zum unbezahlten Entwickler geworden ist — jede Workflow-Änderung läuft über dessen Kalender. Die Plattform verkauft sich als No-Code; die operative Realität ist Code durch Klicken, und Klicken skaliert nicht und lässt sich nicht an Software delegieren.

Was ich daraus gemacht habe: AppSheet-Konfiguration als agentenlesbaren Code

Ich habe kürzlich eine komplexe AppSheet-Konfiguration migriert — die unordentliche, über Jahre gewachsene Art mit verflochtenen Slices, Bots und Sicherheitsfiltern — in eine konventionelle Codebasis. Hier die ehrliche Mechanik dieses Wegs, denn die Angst ist immer „wir verlieren die App, die wir haben”:

• Was AppSheet beim Export liefert: ein Ordner mit Definitionsdateien (YAML/JSON-artig), die Tabellen, Spalten und Regeln beschreiben. Das sind Daten, aber nicht lesbar — Semantik über Dateien verstreut, ohne Reihenfolge, ohne Erklärung, warum eine Regel existiert.
• Das Mapping, das funktioniert: Tabellen → Datenbankschema; Slices → Abfragen/Views; Bots → geplante Workflows; virtuelle Spalten → berechnete Felder; Sicherheitsfilter → Zugriffssteuerung auf Zeilenebene an einem auditierbaren Ort.
• Was das Team behält: denselben Workflow, dieselben Screens nach Zweck, dieselben Daten. Was sich ändert, ist der Ort der Logik — in Code, den ein Mensch oder ein KI-Agent lesen, diffen, an einer Stelle ändern und gegen eine Testsuite verifizieren kann.

Der Unterschied an Tag eins ist banal, aber entscheidend: Eine Regeländerung, die früher ein halber Tag sorgfältiger GUI-Chirurgie war (die richtige Editor-Oberfläche öffnen, den Nachbarausdruck nicht anfassen, manuell neu testen), wird zu einer kleinen Codeänderung, die ein Agent in Minuten anwendet und eine Testsuite validiert. Wartung hört auf, eine Klick-Spezialistenübung zu sein, und wird überprüfbare Arbeit.

Das ist der eigentliche Burggraben im Jahr 2026 — nicht die Datenbank, nicht das UI-Framework, sondern ob das Artefakt von dem Agenten lesbar ist, den Sie zwangsläufig zu seiner Wartung einsetzen werden. Prompt-evolvierter Code und per Klick konfigurierte Apps bestehen diese Prüfung beide nicht; bewusst strukturierter Code besteht sie.

Wann AppSheet weiterhin die richtige Antwort ist

Wie immer dieselbe Ehrlichkeit: kleines Team (≤10 Nutzer), Standard-Workflow (Formulare, Listen, Genehmigungen nach Vorlage) und jemand intern, der die App betreuen will. Für dieses Profil ist AppSheet für 50–100 $/Monat ein faires Angebot, und das sage ich auch — der Alternativen-Artikel behandelt, wann Bleiben richtig ist.

Gehen Sie, wenn eines davon wahr wird: Die Sitze kriechen über 10–15 hinaus, Sie brauchen API-/Datenbankanbindungen (Enterprise-Plus-Preise), Änderungen stehen im Kalender einer einzigen Person an, oder die Sheets darunter haben 50.000+ Zeilen.

Was kein Pro-Sitz-Abo einschließt

AppSheet, Glide, Retool — jede Plattform dieser Klasse vermietet Ihnen Fähigkeit. Keine schließt die menschliche Schicht ein: jemanden, der untersucht, wie Ihr Betrieb tatsächlich läuft, die Daten mit ihrer Geschichte intakt migriert, auf Infrastruktur deployt, die Sie kontrollieren (ein bescheidener VPS betreibt eine echte Ops-Plattform problemlos — er braucht keine Cloud-Rechnung), und der verantwortlich bleibt, wenn etwas bricht. Diese Schicht existiert nirgendwo als Abo. Es ist ein Mensch, und es ist meine Arbeit.

Quellen und weiterführende Literatur

• AppSheet-Preise — Tarife 5/10/20 $ pro Nutzer/Monat, verifiziert August 2026; Workspace-Editionen mit Core
• AppSheet-Alternativen 2026 — die drei ehrlichen Ausstiege
• Glide vs. AppSheet vs. Eigenentwicklung 2026 — wohin GlideOS jetzt passt
• Migration einer AppSheet-CRM nach Express + relationale Datenbank — die Migration von Ende bis Ende