Stack Defaults
Für jede Grundsatzfrage am Projektanfang ist eine Antwort hinterlegt. Sie greift, wenn dir die Frage egal ist.
Mit diesen Fragen wird üblicherweise auf zwei Arten umgegangen. Die eine stellt sie dir alle: Sprache, Datenhaltung, Frontend, Betrieb. Das klingt nach Freiheit und ist am ersten Tag vor allem eine Liste von Fragen, die du noch nicht beantworten kannst, weil du das Projekt noch nicht kennst. Die andere stellt sie gar nicht — Lovable etwa fragt nichts, sondern baut. Entschieden ist dort genauso, du erfährst es nur später, und nicht als Entscheidung, sondern als Eigenheit.
Wir liegen dazwischen: Vorgaben, benannt und begründet. Vorgaben, weil es in den meisten Vorhaben sowieso darauf hinausläuft — nicht, weil die Frage erledigt wäre. Die Wahl bleibt frei; sie kostet dich nur dann Zeit, wenn du sie ausüben willst.
Was festgelegt ist
Zwölf Entscheidungen, mehr nicht. Sie betreffen die Form deiner Anwendung, die Sprache, den Aufbau der Repositories, Datenhaltung, lokalen Zustand, Anmeldung, Rollen, Mandantentrennung, Frontend, Oberflächenkonventionen, Live-Aktualisierung und das Ziel der Veröffentlichung.
Der Standardweg lautet: eine Web-Anwendung in TypeScript, Frontend mit React, Daten in Postgres bei Neon, veröffentlicht auf Railway, ein Repository für den Code, Anmeldung ja, alles Weitere aus.
Damit ist ein Projekt in unter zwanzig Minuten entschieden.
Was du trotzdem wählen kannst
Alles. Es funktioniert, womit ein Modell umgehen kann, und das ist praktisch jeder verbreitete Stack. Beim Bootstrap wirst du gefragt, wo es zählt; wo du keine Meinung hast, wird entschieden, statt dich in eine Diskussion zu ziehen.
Konkret steht zur Wahl: .NET oder Python statt TypeScript. Statisches HTML statt React. Mehrere Service-Repositories statt einem. Zustandslos statt Postgres. Mandantentrennung mit Zeilenschutz in der Datenbank. Server-Push über SSE oder SignalR. Und ein eigenes Veröffentlichungsziel — das wird dann kein Streitpunkt am ersten Tag, sondern ein Item auf deinem Board.
Auch die Form ist offen: nicht nur die Web-Anwendung, sondern ebenso ein reiner API-Dienst, ein Kommandozeilenwerkzeug oder ein einzelnes Script. Bei den beiden letzten kommt die Frage nach lokalem Zustand dazu, die eine Web-Anwendung nie zu sehen bekommt.
Fünf der zehn Fragen bekommst du auf dem Standardweg gar nicht zu sehen — Sprache, Frontend, Repository-Form, Live-Aktualisierung und Veröffentlichungsziel. Wer sie beantworten will, fragt danach. Wer nicht, bekommt eine Antwort, die trägt. Zwei der zwölf Entscheidungen sind gar keine Fragen: Rollen und Oberflächenkonventionen stehen fest.
Warum das mehr ist als Bequemlichkeit
Hier liegt der eigentliche Grund, und er hat nichts mit Zeitersparnis zu tun.
Ein Sprachmodell scheitert selten daran, dass es nicht programmieren kann. Es scheitert daran, wie viele Wege von einer Anforderung zu einer Umsetzung führen — und wie viele davon in deinem Projekt falsch sind, obwohl sie für sich genommen richtig wären. Zwei Entwickler lösen dieselbe Aufgabe unterschiedlich, und beide Lösungen sind vertretbar. Ein Modell, das bei jedem Item neu wählt, produziert innerhalb weniger Wochen ein Projekt aus vertretbaren Einzelteilen, die nicht zusammenpassen.
Jede festgelegte Entscheidung schneidet Wege ab, bevor jemand sie einschlägt. Das Modell entscheidet nicht mehr, wie gebaut wird. Es füllt aus.
Deshalb steht auch nicht bloß das Ergebnis fest, sondern die Begründung dazu. Ein Etikett — „Postgres" — sagt einem Agenten nichts darüber, ob er für die Testumgebung eine Kopie anlegen soll. Der Grund sagt es ihm.
Die Regel dahinter
Der Bootstrap folgt einem Satz, der auch für alles andere gilt:
Komplexität, die Fehler verhindert, ist gut. Jede andere gehört in den erweiterten Modus.
Prüfung an jeder Systemgrenze ist gut, weil ein Fehler dort mit einer lesbaren Meldung endet statt mit kaputten Daten. Eine zusätzliche Abstraktionsebene, die nur für den Fall da ist, dass irgendwann etwas anders sein könnte, ist es nicht.
Was passiert, wenn eine Entscheidung fehlt
Dann bleibt die Arbeit stehen. Trifft eine Anforderung auf eine Frage, die in deinem Projekt nie beantwortet wurde — es soll benachrichtigt werden, aber niemand hat je festgelegt, wie —, dann schreibt der Agent keine Spezifikation. Er fragt nach und schlägt vor, die Entscheidung festzuhalten.
Das ist der unbequemste Teil des Ablaufs und der wertvollste. Eine fehlende Entscheidung wird sonst still improvisiert, und zwar jedes Mal anders.
Die Bausteine im Einzelnen
- Claude Code — womit gearbeitet wird
- Git und GitHub — wo dein Code liegt
- Neon — wo deine Daten liegen
- Railway — wo deine Anwendung läuft