06. Jan. 2026·7 Min
One-Page-App-Spezifikation: Vorlage für konsistente AI-gebaute Apps
Nutze eine One-Page-App-Spezifikation, um eine vage Idee in klare Prompts für Planning Mode zu verwandeln: Nutzer, Jobs-to-be-done, Entities und Edge-Cases.
Nutze eine One-Page-App-Spezifikation, um eine vage Idee in klare Prompts für Planning Mode zu verwandeln: Nutzer, Jobs-to-be-done, Entities und Edge-Cases.
Eine vage Idee ist zum Träumen ok. Zum Bauen ist sie problematisch.
Wenn du einem AI-Builder einfach „eine App zum Tracken von Gewohnheiten“ gibst, muss er raten, was du meinst. Diese Annahmen ändern sich von Prompt zu Prompt, also ändert sich auch die App. Am Ende hast du Bildschirme, die nicht zusammenpassen, Daten, die mitten im Build umbenannt werden, und Features, die auftauchen, verschwinden und in anderer Form wiederkommen.
Diese Inkonsistenz zeigt sich meist an ein paar Stellen:
„Planning Mode“ ist eine einfache Pause vor dem Bauen. Du notierst die Entscheidungen, die der AI-Builder sonst erfinden würde. Es geht um Konsistenz: eine feste Reihe von Entscheidungen, der UI, Backend und Datenbank folgen.
Das Ziel ist nicht Perfektion. Es ist ein Build, den du iterativ anpassen kannst, ohne dauernd Patches auf Basis von Vermutungen zu kleben. Wenn du dich später umentscheidest, aktualisierst du eine kleine Spezifikation und baust mit derselben Logik neu.
Deshalb ist eine einseitige App-Spezifikation wichtig. Sie ist kein langes PRD und keine wochenlangen Diagramme. Sie ist eine Seite, die vier Dinge beantwortet: wer die Nutzer sind, was sie erreichen wollen, welche Daten existieren (in klarer Sprache) und welche Edge-Cases oder Non-Goals verhindern, dass die erste Version aus dem Ruder läuft.
Beispiel: „Eine Booking-App“ wird viel klarer, sobald du entscheidest, ob sie für einen einzelnen Salonbesitzer oder einen Marktplatz gedacht ist und ob Kunden umbuchen, stornieren oder nicht erscheinen dürfen.
Eine One-Page-Spec ist eine kurze Notiz, die eine vage Idee in klare Anweisungen verwandelt. Du „desingst“ nicht das ganze Produkt. Du gibst dem AI-Builder genügend Struktur, damit er bei jeder Ausführung dieselben Entscheidungen trifft.
Die Seite hat vier Blöcke. Wenn es nicht auf eine Seite passt, hast du wahrscheinlich zu viele Features für die erste Version.
Eine Seite erzwingt nützliche Einschränkungen. Du wählst einen primären Nutzer, definierst den kleinsten erfolgreichen Flow und vermeidest vage Versprechen wie „alles unterstützen“. Genau diese Einschränkungen verhindern, dass eine AI-gebaute App ihre Meinung zwischen Screens ändert.
„Gut genug“ Detail sind einfache, testbare Aussagen. Wenn jemand es lesen und fragen kann: „Woran merken wir, dass es funktioniert?“, bist du auf dem richtigen Level.
Eine kurze Messlatte:
Halte die Sprache einfach. Schreibe Sätze, die du direkt in Prompts einfügen könntest, wie „A manager can approve or reject a request, and the requester gets a status update.".
Stell einen 20-Minuten-Timer und ziele auf „klar genug zum Bauen“, nicht auf „perfekt“. Es geht darum, die Raterei zu entfernen, damit der AI-Builder dieselben Entscheidungen trifft.
Beginne mit einem einzigen Satz, der beantwortet: Für wen ist es und welches Ergebnis bekommen sie?
Beispiel: „Eine mobile App für Hundebesitzer, um Spaziergänge und Tierarztbesuche an einem Ort zu erfassen."
Wenn du es nicht in einem Satz sagen kannst, handelt es sich wahrscheinlich um zwei Apps.
Nenne dann 1–3 Nutzertypen wie reale Personen, nicht abstrakte Rollen. „Owner“, „Vet“ und „Family member“ sind besser als „User A“. Füge für jeden eine kurze Zeile hinzu, worauf es ihnen am meisten ankommt.
Schreibe anschließend 3–7 Jobs-to-be-done im Format: „When [Situation], I want to [Action], so I can [Result].“ Halte sie testbar. „When I finish a walk, I want to log distance and notes, so I can spot patterns" ist klarer als „track health."
Definiere nun deine Entities und Schlüssel-Felder ohne Datenbank-Jargon. Denke an „Dinge, an die sich die App erinnert“. Für die Hunde-App: Dog (Name, Alter), Walk (Datum, Dauer, Notizen), Visit (Datum, Klinik, Kosten). Wenn ein Feld in keinem Screen oder Job verwendet wird, lass es weg.
Beende mit zwei kurzen Blöcken: Edge-Cases und Non-Goals. Edge-Cases sind lästig, aber üblich (z. B. „kein Internet“, „zwei Hunde mit demselben Namen"). Non-Goals sind Dinge, die du noch nicht baust („keine Zahlungen“, „kein Social Feed").
Konvertiere schließlich jeden Block in Prompts, denen dein Builder folgen kann. Eine konsistente Struktur (Zweck, Nutzer, Jobs, Entities, Edge-Cases) hilft dem System, Screens, Daten und Flows zu erzeugen, die zusammenpassen.
Wenn deine Spec „für alle“ sagt, muss ein AI-Builder raten, was zuerst gebaut wird. In einer One-Page-Spec definierst du Nutzer nach Absicht (was sie erreichen wollen), nicht nach Demografie. Absicht führt zu klaren Entscheidungen über Screens, Daten und Berechtigungen.
Nenne 2–4 Nutzertypen, jeweils mit einem Hauptziel. Gute Beispiele: „Customer placing an order“, „Team member fulfilling orders“, „Manager reviewing performance“. Vage Beispiele sind „18–35“, „busy professionals“ oder „admins“ (es sei denn, du beschreibst, was sie adminen).
Verwende jedes Mal denselben Satzbau: „When..., I want to..., so I can...“. Das hält die App ergebnisorientiert und gibt deinem AI-Builder stabile, testbare Anforderungen.
Hier realistische JTBD-Beispiele mit eindeutigem „done":
Akzeptanzkriterien sind wichtig, weil sie „sieht gut aus“ Ambiguität entfernen. Sie sagen dem Builder, was die UI erlauben muss und was das Backend speichern soll.
Schreibe keinen vollständigen Sicherheitsplan. Sag einfach, wer was darf, in klarer Sprache.
Beispiel: „Members can create and edit their own items. Managers can edit any item and change status. Owners can manage users and billing."
Wenn du einen Planning-Step in einem Tool wie Koder.ai (koder.ai) nutzt, werden diese Nutzer-Typen, JTBD-Zeilen und Berechtigungen zu verlässlichen Eingaben. Sie verhindern auch, dass die KI zusätzliche Rollen erfindet oder Verantwortungen zwischen Screens vermischt.
Entities sind die „Dinge“, die deine App nachverfolgt. Wenn du sie klar benennst, kann dein AI-Builder passende Screens, Formulare und eine Datenstruktur generieren. Das verhindert inkonsistente Felder und zufällige Extras.
Beginne mit einer Liste deiner Kern-Nomen. Für „Projektmanagement“ wären das Project, Task, Comment. Für „Haarschnitt-Buchung“ könnten es Booking, Service, Customer und Staff sein.
Für jede Entity schreibe Felder in Alltagssprache, nicht in DB-Begriffen. Stell dir vor, was jemand in ein Formular eingeben würde.
Wenn du ein Feld nicht in einem Satz erklären kannst, ist es wahrscheinlich zu detailliert für v1.
Beschreibe, wie Entities verbunden sind, in einfachen Sätzen:
„Ein Nutzer kann viele Projekte haben.“ „Jede Aufgabe gehört zu einem Projekt.“ „Ein Kommentar gehört zu einer Aufgabe und hat einen Autor.“
Das gibt dem Builder genug Struktur, um konsistente Listen, Detailseiten und Filter zu erzeugen.
Füge ein paar Datenregeln hinzu, die schlechtes Verhalten verhindern:
Schränke den Umfang weiter ein, indem du nennst, was du noch nicht speichern wirst. Beispiel: „No file attachments in v1" oder „Don’t track staff schedules yet, only bookings." Diese Ausschlüsse verhindern, dass die App in die falsche Richtung wächst.
Eine One-Page-Spec funktioniert am besten, wenn die erste Version wenige, stabile Screens hat. Wenn du versuchst, jeden möglichen Screen für später zu designen, wird dein AI-Builder raten und die UI wird zwischen Builds abdriften.
Beginne damit, die minimalen Screens zu benennen, die jemanden die Hauptaufgabe abschließen lassen. Für die meisten MVPs reichen 3 bis 6 Screens:
Schreibe den Happy Path als kurze Geschichte von Anfang bis Ende.
Beispiel: „User signs in, lands on the list, searches, opens an item, edits one field, saves, and returns to the list."
Notiere für jeden Screen die wichtigsten Aktionen in einfachen Worten. Vermeide „alles tun“-Screens. Wähle 2–4 Aktionen, die am meisten zählen: create, edit, search, export, archive.
Entscheide außerdem, was schnell sein muss und was „gut genug“ ist. „Schnell“ heißt meist: die Liste öffnet schnell, die Suche reagiert schnell, Speichern fühlt sich instant an. „Gut genug“ könnte Export in wenigen Sekunden, einfache Analytics oder spärliche Einstellungen sein.
Halte Rollen und Zugriff in einer Zeile pro Rolle fest:
Das macht Screens vorhersehbar, verhindert Berechtigungs-Überraschungen und reduziert spätere Nacharbeiten.
Die meisten Neubauten passieren aus einem Grund: die App funktioniert im Happy Path, bricht aber, wenn das echte Leben auftaucht.
Eine gute One-Page-Spec macht Platz für Edge-Cases und Non-Goals — dieser kleine Raum spart Stunden.
Beginne bei jedem Job-to-be-done und frage: Was könnte schiefgehen? Formuliere es einfach, nicht technisch. Du entfernst Ambiguität, damit der Builder bei jeder Ausführung dieselbe Entscheidung trifft.
Gängige Edge-Cases, die es wert sind aufzuschreiben:
Bestimme dann die Reaktion. Sei spezifisch: „Blockiere die Aktion und zeige eine klare Meldung“, „Speichere als Entwurf“, oder „Versuche einmal neu, dann zeige einen Button zum erneuten Versuch“. Diese Regeln übersetzen sich direkt in konsistente Prompts.
Füge Datenschutz- und Sicherheits-Erwartungen in ein oder zwei Zeilen hinzu. Beispiel: „Sammle nur die minimal nötigen Daten“, „Nutzer können ihr Konto und alle persönlichen Daten löschen“, „Private Elemente standardmäßig verbergen“. Wenn die App nutzergenerierte Inhalte hat, notiere, wie mit Meldungen und Spam umgegangen wird, auch wenn es in v1 einfach bleibt.
Schreibe schließlich Non-Goals, um Scope Creep zu stoppen. Wähle die größten verlockenden Features, die du noch nicht machen willst.
Beispiele für klare Non-Goals:
Ein kurzes Beispiel: Wenn der Job „Create an event“ ist, definiere, was passiert, wenn das Datum in der Vergangenheit liegt, der Titel leer ist oder dasselbe Event zweimal erstellt wird. Diese Klarheit verhindert den nächsten Neubau.
Der schnellste Weg zu konsistenten Ergebnissen ist, jeden Block deiner One-Page-Spec in einen kleinen, direkten Prompt zu verwandeln. Denk daran wie Karten, denen der Builder nacheinander folgen kann, statt einer großen, vagen Aufforderung.
Konvertiere jeden Block (Users, Jobs, Entities, Screens, Edge-Cases, Non-Goals) in eine Anweisung mit klaren Substantiven und Verben. Vermeide Meinungen wie „make it clean“, außer du sagst, was „clean" konkret bedeutet.
Verwende einen Zwei-Schritt-Zyklus: zuerst bauen, dann gegen die Spec prüfen.
Füge eine kurze Definition von done hinzu, damit der Builder weiß, wann er aufhören soll. Halte es messbar:
Füge nur Einschränkungen hinzu, wenn sie wirklich zählen: benötigte Geräte (mobile-first), erforderliche Auth (nur Admin-Aktionen) oder benötigte Technologie (z. B. React-Frontend, Go-Backend, PostgreSQL), falls deine Plattform das erwartet.
Wenn du Änderungen willst, beziehe dich auf den Spec-Block, nicht auf den Code.
Beispiel: „Update the Entities block: add ‘Subscription’ with fields X and Y. Then regenerate only the affected APIs and screens, and re-run the validation step."
Dieser Ansatz hält den Plan stabil und erlaubt sichere Iteration.
Stell dir vor, du willst einen einfachen Termin-Erinnerungs-Tracker für einen kleinen Salon. Ziel ist kein vollständiges Buchungssystem. Es ist ein leichtgewichtiger Ort, um Termine zu speichern und Erinnerungen zu senden.
So sieht eine ausgefüllte One-Page-Spec aus.
APP: Appointment Reminder Tracker
GOAL: Track appointments and send reminders. No payments, no online booking.
USERS
1) Owner/Staff: creates and manages appointments, wants fewer no-shows.
2) Client: receives reminders, wants an easy way to confirm.
JOBS TO BE DONE (JTBD)
1) As staff, I add an appointment in under 30 seconds.
2) As staff, I see today's schedule in time order.
3) As staff, I mark a client as confirmed or no-show.
4) As staff, I resend a reminder when asked.
5) As a client, I confirm from a message without creating an account.
ENTITIES (DATA)
- Client: id, name, phone, email (optional), notes
- Appointment: id, client_id, service, start_time, duration_min, status (scheduled/confirmed/canceled/no_show)
- Reminder: id, appointment_id, channel (sms/email), send_at, sent_at, result (ok/failed)
- StaffUser: id, name, role (owner/staff)
Relationships: Client 1-to-many Appointment. Appointment 1-to-many Reminder.
EDGE CASES (WHAT BREAKS NAIVE BUILDS)
1) Duplicate client (same phone, different name)
2) Overlapping appointments for the same staff
3) Time zone changes (travel, daylight saving)
4) Client has no email, SMS only
5) Reminder send fails, needs retry and visible status
6) Appointment edited after reminder scheduled
7) Client cancels after confirmation
8) Same-day appointment created 10 minutes before start
9) Phone number format varies (+1, spaces, dashes)
10) Deleting a client with future appointments
Wandle das nun in ein Prompt-Bundle für Planning Mode um. Halte es strikt, damit der Builder immer dieselben Entscheidungen trifft.
PLANNING MODE PROMPT BUNDLE
1) Build an MVP web app with these entities and relationships exactly as written.
2) Required screens: Login (StaffUser), Today Schedule, Client List, Client Detail, Appointment Create/Edit.
3) Required flows: create client, create appointment for a client, confirm/cancel/no-show, schedule reminders, resend reminder.
4) Constraints: no payments, no public booking page, no client accounts.
5) Edge-case handling: implement validation and UI feedback for all 10 edge cases listed.
6) Output: database schema, API endpoints, and UI behavior notes per screen.
Unordentliche Ergebnisse beginnen meist mit einer vagen Spezifikation und Feature-Wunschlisten. Eine KI macht, was du sagst, aber sie kann deine Gedanken nicht lesen. Kleine Lücken werden zu großen Unterschieden zwischen Screens und Flows.
Fallen, die Konsistenz am häufigsten brechen, und wie die One-Page-Spec sie behebt:
Wenn du Planning Mode in Koder.ai (koder.ai) nutzt, sind diese Basics noch wichtiger, weil der Plan zur Grundlage wiederholter Prompts wird. Klare Jobs, ein kleines Datenmodell, explizite Berechtigungen und testbare Erfolgskriterien halten jeden neuen Screen mit dem Rest in Einklang.
Vor dem Bauen mach einen schnellen Durchgang deiner One-Page-Spec. Ziel ist, die Lücken zu schließen, die eine KI zwingen zu raten. Diese Raterei führt zu Neubauten.
Kurze Vollständigkeitsprüfung:
Wenn du ein einfaches Scoring willst, bewerte jeden Bereich von 0 bis 2:
Ziel: mindestens 7 von 10. Wenn Entities oder Edge-Cases unter 2 liegen, repariere die zuerst. Sie verursachen den meisten Aufwand.
Nach dem ersten Build prüfe die App gegen jede Job-to-be-done und markiere Abweichungen. Mach einen Snapshot vor jeder Änderung. Wenn eine Iteration Dinge schlechter macht, rolle zurück und versuche eine kleinere Änderung.
Wenn du Koder.ai (koder.ai) nutzt, ist Planning Mode ein praktischer Ort, um diese One-Page-Spec als „Quelle der Wahrheit“ zu behalten und nur das neu zu generieren, was sich geändert hat, statt alles manuell neu zu schreiben.
Halte die Spec aktuell: Wenn du eine Änderung akzeptierst, aktualisiere die Spec noch am selben Tag. Wenn du eine Änderung ablehnst, schreibe auf, warum, damit der nächste Prompt konsistent bleibt.
Planning Mode ist eine kurze Pause, in der du wichtige Entscheidungen bevor der Bildschirm- und Code-Generierung notierst. Ziel ist Konsistenz: dieselben Nutzer, Abläufe und Datenbezeichnungen in UI, Backend und Datenbank, damit du nicht ständig wegen neuer Annahmen neu bauen musst.
Beginne mit einem Ein-Satz-Ziel und fülle dann vier Blöcke aus:
Wenn es nicht auf eine Seite passt, kürze Features für v1.
Praktisch und intents-basiert. Nenne wenige Nutzerarten und was sie erreichen wollen.
Beispiel: „Owner/Staff, der Termine anlegt“ ist klarer als „Admin“. Wenn du eine Rolle nicht in einem Satz erklären kannst, ist sie wahrscheinlich zu vage.
Nutze ein striktes Muster, damit jede Aufgabe testbar ist:
Füge eine kurze Definition von "done" hinzu (was gespeichert/aktualisiert/sichtbar sein muss). So verhindert man, dass der Builder zusätzliche Schritte oder zufällige Screens erfindet.
Liste die Dinge, die die App sich merken soll, in Alltagssprache und gib jedem 3–7 Felder, die du wirklich auf Screens brauchst.
Beispiel: Appointment: Startzeit, Dauer, Status, Service, Client. Felder, die nicht in einem Job oder Screen genutzt werden, lass für v1 weg.
Formuliere Beziehungen als einfache Sätze:
Füge ein paar Basisregeln hinzu (Pflichtfelder, eindeutige Felder, Defaults). Das reicht meist, damit Listen, Formulare und Filter konsistent sind.
Als Standard 3–6 Screens, die den Haupt-Job end-to-end erlauben:
Schreibe zudem einen kurzen Happy-Path (Start → Aktion → Speichern → Bestätigung), damit der Ablauf nicht driftet.
Edge-Cases zeigen, wo der Happy-Path bricht. Notiere die Top 5–10, die wahrscheinlich sind:
Für jeden Fall sag, wie die App reagieren soll (Blockieren + Meldung, Entwurf erlauben, einmal neu versuchen, etc.).
Wandle jeden Block in eine kurze Anweisung, die der Builder ausführen und prüfen kann.
Ein einfacher Ablauf:
So vermeidest du eine einzige, leicht missverständliche Riesen-Anweisung.
Ändere zuerst die Spezifikation, dann regeneriere nur das, was betroffen ist.
Beispiel: „Füge die Entity Subscription mit Feldern X/Y hinzu; aktualisiere die betroffenen APIs und Screens; führe die Validierung erneut aus.“ Die Spec bleibt damit die Quelle der Wahrheit und verhindert verstreute, inkonsistente Änderungen.