Methode SOCLE
Framework zur Erstellung digitaler Produkte in 5 aufeinanderfolgenden Schritten. Jeder Schritt liefert konkrete Ergebnisse, die den nächsten Schritt speisen.
Prinzip
Der gesamte Boden wird vorbereitet, bevor die erste sichtbare Funktion gebaut wird. Jede Entscheidung wird einmal getroffen, in der richtigen Reihenfolge. Die technischen Grundlagen werden in einem Durchgang gelegt, einschließlich dem, was später gebaut wird. Die Entwicklung erfolgt in kurzen, in sich geschlossenen Inkrementen – jedes wird vollständig abgeschlossen und ausgeliefert, bevor das nächste beginnt.
Die 5 Schritte
S — Strukturieren (Entscheidungen treffen)
Beginnen Sie mit den Entscheidungen, die zählen. An wen richtet sich das Produkt, welches Problem wird gelöst, welche Technologien werden verwendet, wie wird gemessen. Eins nach dem anderen, in der richtigen Reihenfolge, und jedes öffnet die Tür zum nächsten.
Ergebnisse dieses Schrittes:
- Produktvision in einem Satz
- Zielnutzer (primäre und sekundäre Persona)
- Gelöstes Problem (spezifisch, messbar)
- Festgelegter Technologie-Stack
- Ausgewählte visuelle Richtung
- Identifiziertes Monetarisierungsmodell (auch wenn Freemium, auch wenn später)
- Produktname
Vorgehensweise:
- Strukturierte Fragen mit geschlossenen Antwortmöglichkeiten stellen (kein offenes Brainstorming)
- Jede Entscheidung festlegen, bevor zur nächsten übergegangen wird
- In einer Tabelle der festgelegten Entscheidungen zusammenfassen
- Wettbewerber und Unterscheidungsmerkmale identifizieren
Lesen Sie references/structurer-checklist.md für die vollständige Liste der zu treffenden Entscheidungen.
O — Ausstatten (Das Fundament legen)
Bereiten Sie das gesamte Terrain in einem einzigen Durchgang vor. Die Datenbank, die Seiten, die Authentifizierung, das Tracking, die Konventionen. Alles ist bereit, auch für das, was später gebaut wird.
Ergebnisse dieses Schrittes:
- Endgültige Routenstruktur (die URLs werden sich nicht mehr ändern)
- Vollständiges Datenbankschema (alle Tabellen, auch die in V0.1 nicht verwendeten)
- CSS-Design-Tokens (Variablen, Typografie, Farben, Abstände)
- Animationsvarianten (Framer Motion oder Äquivalent)
- Analytics-Tag-Plan (Events, Conversion-Funnel)
- CI/CD-Pipeline (Lint, Type-Check, Tests, automatischer Build)
- Datei CLAUDE.md (Projektanweisungen für Claude Code)
- Datei CURRENT_INCREMENT.md (Umfang des ersten Inkrements)
- Middleware-Konfiguration (Auth, Weiterleitungen, Sicherheitsheader)
- Dokumentierte Umgebungsvariablen
Vorgehensweise:
- Vollständige Routenstruktur generieren (Marketing, Auth, App, Admin, API)
- Vollständiges SQL-Schema mit Enums, Indizes, RLS und Triggern schreiben
- Designsystem konfigurieren (globals.css + tailwind.config.ts)
- Projektkontext-Dateien erstellen (CLAUDE.md, ARCHITECTURE.md, usw.)
- Projekt aufsetzen, alle Abhängigkeiten installieren, erster Commit, deployen
Lesen Sie references/outiller-templates.md für die Vorlagen jeder Datei.
C — Bauen (In Inkrementen)
Arbeiten Sie in kurzen Inkrementen. Jedes Inkrement liefert etwas Vollständiges, das gezeigt, getestet und verwendet werden kann. Ein echtes Stück Produkt, das vom Anfang bis zum Ende funktioniert.
Prinzipien:
- Jedes Inkrement hat einen abgeschlossenen Umfang, der in CURRENT_INCREMENT.md festgelegt ist
- Jedes Inkrement hat testbare Fertigstellungskriterien
- Jedes Inkrement hat eine explizite Liste dessen, was nicht im Umfang enthalten ist
- Aufgaben sind geordnet: Jede Aufgabe hängt nur von den vorherigen ab
- Jede Aufgabe folgt dem Zyklus: codieren, testen, prüfen, committen
Struktur eines Inkrements:
# V0.X — [Name des Inkrements]
## Ziel
[Was der Benutzer am Ende dieses Inkrements tun kann]
## Aufgaben (in der Reihenfolge)
[Nummerierte Liste der Aufgaben mit Details]
## Fertigstellungskriterien
[Liste konkreter Überprüfungen]
## Nicht im Umfang
[Explizite Liste von allem, was NICHT in diesem Inkrement enthalten ist]
Systematische Überprüfungen nach jeder Aufgabe:
- Der Type-Check läuft durch
- Die Tests laufen durch
- Keine
any-Typen - Props sind typisiert
- API-Eingaben sind validiert
- Der Commit folgt den Conventional Commits
L — Ausliefern (In jedem Schritt)
Jedes Teil ist online und in den Händen echter Benutzer, bevor das nächste angegangen wird. Feedback kommt früh, Anpassungen auch.
Prinzipien:
- Jedes Inkrement wird in Produktion (oder Preview) deployt, sobald es fertig ist
- Der Deploy ist automatisch (Push auf main = Deploy auf Vercel)
- Produktionsfehler werden sofort erkannt (Monitoring, Error Boundaries)
- Analytics-Events sind ab dem ersten Inkrement aktiv
- Das nächste Inkrement wird erst begonnen, wenn das vorherige stabil ist
Checkliste für die Auslieferung:
- Build läuft in CI durch
- Null Konsolenfehler in der Produktion
- Seiten haben Metadaten (Titel, Beschreibung)
- Responsives Design funktioniert (mobil prüfen)
- Analytics-Events werden getrackt
- Die URL ist erreichbar und funktionsfähig
E — Erweitern (Ohne Neuanfang)
Das Produkt wächst natürlich. Neue Funktionen bauen auf dem Bestehenden auf, das Design entwickelt sich weiter, Integrationen werden angeschlossen. Die Struktur bleibt stabil, weil der Boden von Anfang an bereit war.
Prinzipien:
- Neue Inkremente invalidieren niemals die vorherigen
- DB-Tabellen sind bereits vorhanden (in Schritt O hinzugefügt)
- CSS-Variablen ermöglichen Stiländerungen ohne Komponentenänderungen
- Routen sind stabil (URLs ändern sich nicht)
- Code-Konventionen sind vom ersten bis zum letzten Inkrement gleich
Wenn ein Inkrement hinzugefügt wird:
- CURRENT_INCREMENT.md mit dem neuen Umfang aktualisieren
- Prüfen, ob die Grundlagen (Schritt O) die Anforderungen abdecken
- Fehlt eine Tabelle oder Route: per Migration hinzufügen, nicht durch Neukonstruktion
- Codieren, testen, deployen nach denselben Konventionen wie V0.1
So wenden Sie SOCLE auf ein neues Projekt an
Vollständiger Ablauf
1. STRUKTURIEREN
│ Strukturiertes Gespräch (geschlossene Fragen)
│ Tabelle der festgelegten Entscheidungen
│ Vision, Zielgruppe, Stack, Monetarisierung
↓
2. AUSSTATTEN
│ Alle Gründungsdateien generieren
│ Routen, DB, Tokens, Analytics, CI/CD
│ Aufsetzen, deployen, erster leerer Commit
↓
3. BAUEN (V0.1)
│ Erstes Inkrement: der minimale Kern
│ Auth + eine Kernfunktion + ein Export
│ Tests, Commit, Deploy
↓
4. AUSLIEFERN (V0.1)
│ In Produktion, getestet von echten Benutzern
│ Analytics aktiv, Fehler überwacht
│ Stabil, bevor mit V0.2 fortgefahren wird
↓
5. ERWEITERN (V0.2, V0.3, ...)
│ Jedes Inkrement folgt C → L
│ Die Grundlagen absorbieren das Wachstum
│ Kein Neuanfang
Zu generierende Projektdateien (Schritt O)
| Datei | Rolle |
|---|---|
CLAUDE.md | Anweisungen für Claude Code: Konventionen, Workflow, Überprüfungen |
CURRENT_INCREMENT.md | Umfang des aktuellen Inkrements, geordnete Aufgaben, Fertigstellungskriterien |
ARCHITECTURE.md | Endgültige Routen, Dateistruktur, Datenfluss |
DB_SCHEMA.sql | Vollständiges Datenbankschema |
DESIGN_TOKENS.md | CSS-Variablen, Tailwind-Konfiguration, Animationsvarianten |
AGENT_PROMPTS.md | System-Prompts, falls das Projekt KI-Agenten verwendet |
ROADMAP.md | Überblick über alle geplanten Inkremente |
Komplexitätsprüfung (zwischen S und O)
Bevor Sie zu Schritt O übergehen, erstellen Sie eine Bestandsaufnahme aller Projektkomponenten und bewerten Sie deren Komplexität. Wenn die Anzahl der Komponenten mit hoher Komplexität 5 übersteigt, teilen Sie sie in mehr Inkremente auf. Die Regel: Jedes Inkrement enthält maximal 3 bis 5 neue Komponenten.
| Komponente | Komplexität | Vorgesehenes Inkrement |
|---|---|---|
| [Name] | Niedrig / Mittel / Hoch | V0.X |
Wenn das Projekt einer Kathedrale ähnelt (mehr als 20 Komponenten, mehr als 6 mit hoher Komplexität), überdenken Sie den Umfang. Vereinfachen Sie V0.1, bis es von einer Person in ein bis zwei Wochen realisierbar ist.
Empfohlener Technologie-Stack
Die SOCLE-Methode funktioniert mit jedem Stack. Hier ist der Standard-Stack, falls der Benutzer keine Präferenz hat:
| Ebene | Technologie |
|---|---|
| Framework | Next.js 14+ (App Router) |
| Sprache | TypeScript (streng) |
| Styling | Tailwind CSS + shadcn/ui |
| Animationen | Framer Motion |
| Zustand | Zustand |
| Auth | Supabase Auth |
| Datenbank | Supabase (PostgreSQL) |
| Validierung | Zod |
| Tests | Vitest + Testing Library |
| CI/CD | GitHub Actions |
| Deploy | Vercel |
Falls der Benutzer einen anderen Stack verwendet, passen Sie die Vorlagen aus Schritt O entsprechend an. Die SOCLE-Prinzipien bleiben unabhängig vom Stack gleich.
Ton und Haltung
Bei der Anwendung von SOCLE mit einem Benutzer:
- Professioneller, reifer, gesprächiger Ton
- Klare und direkt nützliche Sätze
- Kein unerklärtes Fachjargon, wenn mit einem Nicht-Entwickler gesprochen wird
- Keine Haltung der Überlegenheit
- Keine rhetorischen Konstruktionen („es ist nicht X, es ist Y“)
- Man führt, man vermittelt, man geht gemeinsam voran