# Scoping: von der Idee zur Featureliste

Bevor du die erste Zeile Code generierst, brauchst du eine klare Featureliste und ein Verständnis davon, was in welcher Stufe gebaut wird. Ohne Scoping baust du entweder zu viel (und bist nach 8 Stunden bei einer halbfertigen Login-Seite) oder zu wenig (und hast am Ende einen weiteren Wegwerf-Klick-Dummy ohne echten Nutzen).

Dieses File hilft dir, deine Idee in vier Reifestufen zu zerlegen: Prototyp, MVP, Release, Feature-Ready.

## Die vier Stufen

| Stufe | Zweck | Nutzer | Datenhaltung | Auth |
|---|---|---|---|---|
| Prototyp | Beweisen dass die Kern-Idee funktioniert | Du selbst, 1-2 Testpersonen | In-Memory oder lokale SQLite reicht | Keine oder hartkodiert |
| MVP | Echte Nutzer, erstes Feedback | 10 bis 100 | Postgres, simples Schema | Email-Login oder Magic-Link |
| Release | Zahlende Kunden oder ernsthafte Adoption | 100+ | Postgres mit Migrationen, Backups | OAuth oder Passwort, 2FA optional |
| Feature-Ready | Plattform mit eigenem Ökosystem | 1000+ | Multi-Tenant, Read-Replicas | RBAC, Audit-Log, API-Keys |

Der Workshop heute zielt auf Prototyp. Alles, was darüber hinaus geht, ist Bonus und sollte für später geparkt werden.

## Schritt 1: Die Idee in einem Satz

Schreibe deine Idee in genau einem Satz nach diesem Muster:

> [Zielgruppe] kann [Hauptaktion] machen und bekommt dadurch [Nutzen].

Beispiele:
- Studierende der CAU kann Lerngruppen-Termine erstellen und bekommt dadurch Mitlernende per Push-Benachrichtigung.
- Kleine Cafés in Kiel können Sitzplätze online buchbar machen und vermeiden dadurch leere Tische zu Stoßzeiten.
- Eltern können Schul-Wochenpläne ihrer Kinder zentral einsehen und sparen sich das Abfotografieren von Zetteln.

Wenn du den Satz nicht in einer Zeile schreiben kannst, ist die Idee noch nicht scharf genug. Vor dem Bauen den Satz präzisieren.

## Schritt 2: Akteure benennen

Wer benutzt die App? Liste alle Rollen auf. Für die meisten Prototypen reichen ein bis zwei.

Beispiel Buchungs-App für ein Café:
- Gast (öffentlich, sucht freien Tisch, bucht)
- Café-Betreiber (sieht alle Buchungen, kann Tische sperren, ändert Öffnungszeiten)

Beispiel Lerngruppen-App:
- Studierender (erstellt Gruppe, tritt bei, sieht Termine)
- (Admin später, nicht im Prototyp)

Jede Rolle braucht später eine eigene Sicht. Wenn du eine dritte Rolle entdeckst (zum Beispiel "Moderator"), parke sie für die Release-Stufe.

## Schritt 3: User-Stories sammeln

Schreibe für jede Rolle die wichtigsten Aktionen auf. Format:

> Als [Rolle] möchte ich [Aktion] damit [Grund].

Beispiel Buchungs-App:
- Als Gast möchte ich freie Tische heute Abend sehen damit ich spontan vorbeikomme.
- Als Gast möchte ich einen Tisch für 19 Uhr reservieren damit ich nicht warten muss.
- Als Gast möchte ich meine Reservierung stornieren damit der Platz wieder frei wird.
- Als Café-Betreiber möchte ich alle Buchungen des Tages sehen damit ich planen kann.
- Als Café-Betreiber möchte ich Tische manuell sperren damit Wartung möglich ist.
- Als Café-Betreiber möchte ich Öffnungszeiten setzen damit nur dann gebucht wird.

Pro Rolle 3 bis 7 Stories. Mehr ist nach hinten geplant, nicht jetzt.

## Schritt 4: Zerlegen in Stufen

Nimm jede Story und ordne sie einer Stufe zu. Streng sein. Faustregel:

- **Prototyp**: ohne diese Story ist die Kern-Idee nicht beweisbar.
- **MVP**: nötig damit echte Nutzer es benutzen würden.
- **Release**: nötig damit jemand dafür zahlen würde.
- **Feature-Ready**: Komfort, Skalierung, Edge-Cases.

Beispiel Buchungs-App, Stufenzuordnung:

| Story | Stufe |
|---|---|
| Freie Tische heute Abend sehen | Prototyp |
| Tisch für 19 Uhr reservieren | Prototyp |
| Reservierung stornieren | MVP |
| Café-Betreiber sieht alle Buchungen | Prototyp |
| Café-Betreiber sperrt Tische | MVP |
| Café-Betreiber setzt Öffnungszeiten | Release |
| Email-Bestätigung an Gast | MVP |
| SMS-Erinnerung 1h vorher | Release |
| Mehrere Standorte verwalten | Feature-Ready |
| Stripe-Anzahlung bei Buchung | Feature-Ready |

Ergebnis Prototyp-Scope: 3 Stories. Das ist in 8 Stunden machbar. Alles andere wäre Wunschdenken.

## Schritt 5: Datenmodell skizzieren

Aus den Prototyp-Stories ergibt sich das minimale Datenmodell. Schreibe es als Liste mit Feldern:

```
Tisch
  - id
  - nummer
  - sitzplätze

Reservierung
  - id
  - tisch_id
  - gast_name
  - gast_email
  - start_zeit
  - dauer_minuten
  - erstellt_am
```

Zwei Tabellen reichen. Wenn dein Datenmodell im Prototyp mehr als 4 bis 5 Tabellen hat, schneidest du noch nicht streng genug.

## Schritt 6: Was MUSS raus

Das ist der schwerste Teil. Liste explizit auf, was im Prototyp nicht drin ist. Schreibe es als "Nicht im Prototyp" hin und halte dich dran.

Beispiel Buchungs-App, nicht im Prototyp:
- Login für Gäste (Buchung via Email-Adresse, keine Accounts)
- Kalender-Ansicht (Tabelle reicht)
- Mehrere Standorte (eine Adresse hartkodiert)
- Zahlungen
- Mehrsprachigkeit
- Mobile App (Webapp mit responsivem Layout reicht)
- Admin-Login (für Prototyp einfach /admin offen lassen oder Basic-Auth)

Jeder Punkt, den du hier nicht streichst, kostet dich Stunden.

## Anti-Patterns

- "Ich baue erst mal das Login, dann den Rest." Login ist nicht das Kern-Feature deiner App. Baue zuletzt.
- "Ich brauche eigentlich noch Feature X." Nein. Auf die MVP-Liste, weiter.
- Datenmodell mit 12 Tabellen vor der ersten Story. Du baust eine Datenbank, kein Produkt.
- "Es muss schön aussehen." Funktional vor schön. Tailwind-Defaults reichen für den Prototyp.

## Beispiel-Feature-Liste komplett

Lerngruppen-App, Prototyp-Scope:

**Datenmodell**
- Gruppe (id, titel, fach, ort, start_zeit, ersteller_email)
- Teilnehmer (id, gruppe_id, name, email)

**Pages**
- / (Liste aller Gruppen, filterbar nach Fach)
- /gruppe/[id] (Detail, Teilnehmer-Liste, Beitreten-Button)
- /erstellen (Form: Titel, Fach, Ort, Zeit, deine Email)

**API-Endpoints**
- GET /api/gruppen
- POST /api/gruppen
- POST /api/gruppen/[id]/beitreten

**Nicht drin**: Login, Push-Benachrichtigung, Kalender-Sync, Chat, Bewertungen, Suche.

Das ist in 8 Stunden mit AI-Unterstützung bauen. Mit Auth und Push wärst du nach 8 Stunden bei der Hälfte.

## Nächster Schritt

Nimm deine Idee, schreibe sie in einem Satz auf, zerlege sie nach diesem Muster und schicke die Featureliste dem Agent als Kontext. Erst dann beginnt das Bauen. Lies dazu webapp-prompting.md.