To-do-App ohne Code bauen: Anleitung mit KI-Builder

To-do-App ohne Code bauen

Eine To-do-App entsteht bei Zugo aus einer Beschreibung: Sie nennen die Felder einer Aufgabe, die Ansichten und die Regeln fürs Erledigen, der Builder erzeugt daraus ein lauffähiges Projekt. Ein einfacher Build dauert etwa eine Minute und kostet 6 Credits. Jede weitere Änderung kostet 3 Credits und wird einzeln beauftragt.

Dieser Text geht der Reihe nach durch: erst die Frage, was so eine App überhaupt können muss, dann die Entscheidung über die Datenhaltung, dann ein Prompt zum Kopieren, danach Kosten und Grenzen.

Was muss eine To-do-App wirklich können?

Fast jede selbstgebaute Aufgabenliste scheitert an derselben Stelle: Sie kann zu viel. Wer mit Projekten, Unterprojekten, Prioritätsstufen und Zeiterfassung startet, benutzt sie nach zwei Wochen nicht mehr, weil das Eintragen länger dauert als das Erledigen.

Sinnvoll ist der umgekehrte Weg. Bauen Sie zuerst das kleinste Ding, das Sie täglich öffnen würden, und ergänzen Sie erst dann, wenn Ihnen im Alltag etwas fehlt. Die folgende Tabelle zeigt, was in diese erste Fassung gehört und was warten kann.

Zwei Ansichten reichen am Anfang: eine für heute und eine für alles Offene. Ein Archiv erledigter Aufgaben ist nett, wird aber selten geöffnet. Nehmen Sie es trotzdem mit, weil es einen Tag später Arbeit macht, es nachzurüsten.

Reicht der Browser, oder brauche ich eine Datenbank?

Diese Entscheidung fällt vor dem ersten Build, weil sie den Aufbau bestimmt. Sollen die Aufgaben nur auf einem Gerät liegen, braucht es keine Anmeldung und keine Datenbank. Das Projekt bleibt schlank, und niemand muss ein Passwort verwalten.

Sobald dieselbe Liste auf Laptop und Telefon gleich aussehen soll, führt kein Weg an einem Konto vorbei. Dafür ist Supabase da: Anmeldung, Datenbank und Dateien in einem. Wie diese Anbindung praktisch abläuft, steht in KI-App-Builder mit Supabase.

Die ehrliche Reihenfolge lautet: erst eine Woche mit der einfachen Fassung arbeiten, dann entscheiden. Viele merken in dieser Woche, dass sie die App ohnehin nur auf einem Gerät benutzen, und sparen sich den ganzen Anmeldeteil.

Wie sieht ein Prompt aus, der mehr als eine Liste liefert?

Der Unterschied zwischen einer Attrappe und einem brauchbaren Ergebnis liegt fast vollständig in der Menge konkreter Angaben. „Baue eine To-do-App“ ergibt eine hübsche Liste ohne Verhalten. Der folgende Text ergibt etwas, das Sie benutzen können.

Baue eine To-do-App für eine Person, die im Browser läuft und auf dem Telefon gut bedienbar ist.
Eine Aufgabe hat: Titel, Fälligkeitsdatum (optional), Liste (Arbeit, Privat, Einkauf), Notizfeld.
Ansichten: „Heute“ mit allem, was heute oder überfällig ist, und „Alle offenen“ nach Datum sortiert.
Neue Aufgabe wird über ein einziges Eingabefeld oben angelegt, Enter speichert.
Erledigte Aufgaben rutschen mit einer kurzen Animation nach unten in einen aufklappbaren Bereich.
Wischen nach links auf dem Telefon löscht, mit Rückgängig-Hinweis für ein paar Sekunden.
Leerer Zustand: freundlicher Satz und ein Beispiel, nicht nur eine leere Fläche.
Ton der Oberfläche: ruhig, viel Weißraum, keine Verlaufsfarben. Ein Akzentton in Dunkelgrün.

Drei Dinge machen diesen Prompt gut. Er beschreibt das Verhalten und nicht nur die Elemente. Er nennt den leeren Zustand, den Builder sonst gern als leere Fläche ausliefert. Und er legt den Ton der Oberfläche fest, was das Ergebnis sichtbar verändert.

Wie läuft der Aufbau Schritt für Schritt ab?

Zuerst beschreiben Sie das Projekt so, wie Sie es einer Kollegin erklären würden. Dann startet der Build. Eine einfache App steht in etwa einer Minute, eine mehrseitige Anwendung mit Konten braucht einige Minuten mehr. Vor der Übergabe läuft das Ergebnis in einer Sandbox: Ein Build, der dort nicht öffnet, wird gar nicht erst ausgeliefert.

Danach beginnt der Teil, der die eigentliche Arbeit ausmacht, nämlich die Änderungen. Beauftragen Sie sie einzeln. „Fälligkeitsdatum in der Liste rechts anzeigen und überfällige Einträge rot einfärben“ funktioniert besser als zwölf Wünsche in einem Satz, weil Sie nach jedem Schritt sehen, ob es in die richtige Richtung ging.

Am Ende wird veröffentlicht. Das Projekt läuft unter einer Adresse wie meine-liste.zugo.run und lässt sich sofort auf dem Telefon öffnen. Eine eigene Domain können Sie jederzeit verbinden, für den privaten Gebrauch reicht die vorläufige Adresse.

Was kostet eine To-do-App in Credits?

Abgerechnet wird pro Aktion und nicht pro Monat der Nutzung. Dadurch lässt sich der Aufwand vor dem Start recht genau schätzen.

Für die einfache Fassung heißt das: 6 Credits für den Build, dazu fünf bis acht Änderungen, bis Abstände, Farben und der Wischgriff sitzen. Eine Version mit Anmeldung und mehreren Bereichen startet bei 12 Credits und wächst mit jeder zusätzlichen Seite.

Die Tarife: Free gibt Ihnen 5 Credits, Pro kostet 25 $ im Monat mit 200 Credits, Business kostet 99 $ im Monat mit 800 Credits. Zweihundert Credits entsprechen ungefähr 16 mehrseitigen Plattformen oder 33 Builds oder 66 Änderungen. Rechnen Sie damit, dass 5 Credits im kostenlosen Tarif unter den 6 für einen einzigen Build liegen: Der Gratistarif ist ein Rundgang durch die Oberfläche, kein fertiges Projekt.

Wie kommt die App auf das Telefon?

Sie öffnen die veröffentlichte Adresse im mobilen Browser und legen sie auf den Startbildschirm. Das ist eine Funktion des Telefons und kostet nichts. Ob sich das Ergebnis danach wie eine App anfühlt, entscheidet nicht die Technik, sondern Ihr Prompt.

Verlangen Sie deshalb ausdrücklich große Tippflächen, eine feste Leiste am unteren Rand und ein Eingabefeld, das die Tastatur nicht verdeckt. Diese drei Punkte gehören in den ersten Build und nicht in eine spätere Änderung, weil sie das Layout im Kern betreffen.

Erinnerungen laufen am zuverlässigsten per E-Mail über Resend, etwa eine kurze Nachricht am Morgen mit allem, was heute fällig ist. Das ist unspektakulär, funktioniert aber auf jedem Gerät und ohne zusätzliche Berechtigungen.

Wo hört eine gebaute To-do-App auf?

Drei Grenzen, die Sie vor dem Start kennen sollten.

Sehr spezifische Logik entsteht über mehrere Änderungen, nicht über einen einzigen Prompt. Wiederkehrende Aufgaben mit Ausnahmen („jeden ersten Werktag im Monat, außer im August“) sind genau so ein Fall. Das ist kein Mangel, sondern der normale Ablauf: Sie präzisieren, sehen das Ergebnis, präzisieren erneut.

Bei einem wirklich komplexen Produkt ersetzt ein Builder kein Entwicklungsteam. Eine Aufgabenverwaltung für fünfzig Personen mit Rechten, Freigaben und Revisionssicherheit gehört in diese Kategorie. Für sich selbst, ein Paar oder ein kleines Team liegt der Nutzen dagegen sofort auf dem Tisch.

Und die Sandbox-Prüfung sagt nur, dass das Projekt startet. Ob Ihre Sortierung sinnvoll ist und ob Sie die App im Alltag wirklich öffnen, zeigt sich erst nach einer Woche Benutzung. Planen Sie diese Woche und ein paar Änderungen danach fest ein.

Womit fange ich am besten an?

Schreiben Sie eine Woche lang auf, wie Sie Aufgaben heute festhalten, mit Zetteln, Notiz-App oder Nachrichten an sich selbst. Diese Liste ist die beste Vorlage für den Prompt, weil sie Ihre echten Gewohnheiten enthält statt einer idealisierten Vorstellung davon.

Wenn Sie nicht bei einem leeren Feld anfangen möchten, stehen 25 Vorlagen bereit, davon 5 für Spiele. Ein verwandter Aufbau hilft oft mehr als ein exakt passender: Wer lieber in Spalten denkt, findet in Kanban-Board ohne Code bauen die passende Anleitung, und wer eher Gewohnheiten als Aufgaben verfolgt, ist bei Habit-Tracker mit KI erstellen richtig.

Den ersten Build starten Sie auf zugo.dev und sehen danach in Ruhe nach, was von Ihrem Prompt tatsächlich angekommen ist. Dieser erste Abgleich bringt mehr als jede weitere Anleitung, auch mehr als diese hier.