Hilft eine längere Tech-Stack-Liste beim schnelleren Shippen?
Das hängt davon ab, was die Liste auslässt. Eine Stack-Liste nennt Werkzeuge; sie installiert nicht deren Grenzen — verifizierte Webhooks, Mandanten-Scoping, Release-Signierung —, und genau an diesen Nähten bleiben Projekte stecken. Eine kopierte Liste reproduziert die Werkzeuge ohne jede Integration. Listen taugen als Menü zum Recherchieren, aber der Weg zu einem shipfähigen Produkt ist getestetes Plumbing, egal wie du es beschaffst. Die ehrliche Frage ist, was dir deine Abende wert sind.
Die Bookmark-Falle
Vor ein paar Tagen habe ich einen Thread auf X mit dem Stack beantwortet, den ich tatsächlich fahre — mein „2026-Indie-Dev-Stack“, ein Dutzend Werkzeuge in einer Antwort. Die Antwort sammelte über hundert Bookmarks und brachte mehr als hundert Klicks auf diese Website.
Die Statistik war weniger schmeichelhaft: Die meisten Besucher überflogen eine Seite und gingen. Eine Stack-Liste liest sich wie ein fertiger Plan; eine kopierte Liste liefert nichts aus. Jedes Werkzeug muss trotzdem installiert, mit seinen Nachbarn verdrahtet und getestet werden — an den Nahtstellen dazwischen gehen die Wochen verloren.
Dies ist der Beitrag, den die Bookmarks gesucht haben: nicht welche Werkzeuge ich fahre, sondern welches Plumbing bereits tragfähig war — und was ich damit in achtundvierzig Stunden ausliefern konnte.
Wo Projekte tatsächlich sterben
Die meisten Indie-Projekte sterben nicht an ihrem Kernfeature. Sie sterben in Woche eins an Infrastruktur, die nichts mit der Idee zu tun hat. Motivation hat eine Halbwertszeit von etwa achtundvierzig Stunden — jede Stunde fernab des Produkts verbrennt die knappste Ressource, die ein Solo-Build hat.
Der Verlauf der Woche ist bemerkenswert konstant:
- Tag eins: Monorepo-Layout, ESLint,
tsconfig-Pfade, Datenbankmigrationen. - Tag drei: immer noch in der Dokumentation des Zahlungsanbieters, um die Webhook-Idempotenz richtig hinzubekommen.
- Tag fünf: ein Desktop- oder Mobile-Begleiter — eine neue Build-Pipeline, eine neue Auth-Oberfläche, Auto-Updates von Grund auf.
Ein 48-Stunden-Build, Ende zu Ende
Letzte Woche habe ich SpinShare ausgeliefert, ein Windows-natives Desktop-Werkzeug: Ziehe eine Datei im Explorer, tippe Shift, und ein Radialmenü öffnet sich unter dem Cursor; lässt du los, führt das eine lokale Konvertierung oder Operation aus. Keine Popups, nichts wird hochgeladen; die Datei verlässt den Rechner nie.
Der Zeitplan ist der Teil, der sich zu prüfen lohnt: neues Repository, Rust-Kernlogik, ein Offline-Lizenzfluss auf meinen bestehenden Billing-Schienen und eine Einreichung im Microsoft Store — achtundvierzig Stunden Kernentwicklung, Pair-Coding mit einem Agenten und fast kein Prompt-Tuning. Der Agent ist aus einem unglamourösen Grund nicht entgleist: Die Architekturgrenzen, an denen er halluziniert, waren in supastack, meinem eigenen Kit, bereits abgedichtet.
Was folgt, ist die Abrechnung: das Plumbing, das in diesen zwei Tagen nicht gebaut werden musste.
Setup und Leitplanken
pnpm setup verdichtet den Bootstrap auf einen Befehl: Preflight-Checks, Abgleich der Umgebungsvariablen, Abhängigkeitsinstallationen, Datenbankmigrationen. Es gibt keinen ersten Abend, an dem eine funktionierende Umgebung zusammengesetzt wird — das Repository besteht entweder seine eigene Checkliste oder nennt, was fehlt.
Die .ai/-Spiegeldokumente, AGENTS.md und .agents/skills/ sind ein Vertrag, der für den Agenten geschrieben ist und nicht für den Menschen — die Verantwortungsgrenze jedes Pakets, seine Testregeln, seine roten Linien (die Desktop-App ist eine Single-Webview-Shell, die niemals Produkt-UI forkt). Der Projektstruktur-Guide zeigt das Layout, das er liest; der Beitrag zum Agent-Workflow beschreibt den Arbeitsrhythmus.
Grenzen, die schriftlich festgehalten sind, kann ein Agent nicht versehentlich überschreiten.
Abrechnung und Releases kamen fertig mit
Acht Billing-Adapter sitzen hinter einem Vertrag — Stripe, Creem, Polar, Dodo, Lemon Squeezy, Paddle, Whop und PayPal — und ein webhook_event-Ledger macht jede Abwicklung signaturverifiziert und idempotent, bevor sie zu einer Lizenz oder einer E-Mail wird. Meine Arbeit begann stromabwärts davon: Early-Bird-Stufen, die nach Bestellanzahl umschalten, und Ed25519-signierte Offline-Lizenzschlüssel — ein Desktop-Tool muss ohne Netzwerkaufruf aktivierbar sein. Der Billing-Modul-Leitfaden dokumentiert den Fluss, den ich erweitert habe.
Die Release-Seite war ebenso unspektakulär — und genau das ist der Punkt. Die Tauri-2-Pipeline — desktop-release.yml — baut signierte Bundles und erzeugt latest.json per minisign für Stable- und Beta-Kanäle unter Windows (NSIS und msi), macOS (dmg) und Linux (AppImage). Die einzige Paketierungsarbeit, die ich selbst gemacht habe, war ein MSIX-Build für den Microsoft Store; der Desktop-Schnelleinstieg deckt den Rest ab.
Die zehn Prozent, die Nutzer tatsächlich spüren
Hier ist die Rechnung, die eine Stack-Liste verbirgt. Grob neunzig Prozent dessen, was ein Produkt braucht, ist Plumbing, das der Nutzer nie sieht. Unsichtbares Plumbing ist die Arbeit, die ein Fundament tragen sollte — es ist der Teil, der getragen werden kann. Der Rest ist das Produkt.
Weil meines bereits tragfähig war, flossen fast alle meiner achtundvierzig Stunden in die zehn Prozent, die Nutzer spüren — Arbeit, die nie in einen Stack-Kommentar passt und nie entsteht, solange die Woche an Webhooks und Signierung geht:
- Windows-OLE-Drag-Hooks in Rust, damit das Menü nur scharf ist, solange ein echter Datei-Drag mit gedrücktem Shift gehalten wird — nie beim Tippen.
- Ein Multi-Window-Tray-Flow, damit das Tool einen Tastendruck entfernt bleibt, ohne Taskleistenfenster.
- Die Radialmenü-Animation, abgestimmt, bis das Menü sofort statt animiert wirkt.
- Mehr als dreißig lokale Formatkonverter, jeder mit eigenen Unit-Tests.
Der praktische Teil: Preis und Transparenz
Der faire Einwand: „Ich habe Cursor — warum für eine Stack-Liste bezahlen?“ Er bleibt stichhaltig, bis deine eigene Zeit einen Preis hat. Zwei Abende Webhook-Idempotenz kosten dich ein Feature, das du nicht ausgeliefert hast.
Zur Transparenz: Die Dokumentation ist vollständig öffentlich — Verzeichnisstruktur, zwei Web-Engines, plattformübergreifende Synchronisation, alle acht Billing-Adapter, KI-Routing. Mir ist lieber, ein Skeptiker liest sie von Anfang bis Ende und geht, als dass jemand auf eine Überschrift hin kauft; Starter-Kit oder von Grund auf ist die ehrliche Version der Entscheidung.
Zwei praktische Hinweise: Die angezeigten Preise enthalten bereits 100 $ Launch-Ersparnis, und der Checkout unterstützt Alipay. Und ein 50-%-Builder-Cashback — liefere innerhalb von sechzig Tagen ein echtes Produkt aus, teile die Build-Story öffentlich (5.000 organische Views oder 50 organische Likes auf X, Reddit, YouTube oder Ähnlichem) und schick mir den Link per E-Mail: Die Hälfte kommt zurück, und die Lizenz bleibt deine. Die Regeln stehen in den Launch-Cashback-Bedingungen.
Häufige Fragen zu Stack-Listen
Dieselben Einwände tauchen auf, wann immer das Kit zur Sprache kommt. Sie verdienen direkte Antworten.
- Kann ein Agent das nicht alles für mich scaffolden? — Er kann etwas Plausibles erzeugen; er kann die Nahtstellen nicht in einem Durchgang verifizieren. Ein idempotenter Webhook ist getestet, nicht generiert — Scaffolding händigt dir wieder dieselbe Liste aus.
- Macht ein Boilerplate Produkte nicht generisch? — Das Plumbing ist geteilt; das Produkt nicht. SpinShares Drag-Hooks, Tray-Verhalten und Konverter existieren nirgends im Kit — die zehn Prozent, die Kunden sehen, bleiben deine.
- Was, wenn ich nur eine Web-App brauche? — Das Kit ist so oder so der Kauf; Mobile und Desktop sind Oberflächen, die man übernehmen oder ignorieren kann, keine Voraussetzungen. SpinShare existiert, weil die Desktop-Oberfläche bereits gebaut war.
- Ist ein Desktop-Werkzeug wirklich die Käufergeschichte? — Es ist das kürzeste ehrliche Beispiel, das ich habe: zwei Tage von einem leeren Repository bis zur Store-Einreichung. Dasselbe Plumbing trägt auch ein SaaS — die Launch-Checkliste ist die längere Version.
- Warum nicht einfach die Stack-Liste veröffentlichen? — Erledigt: Der Tech-Stack-Guide nennt jede Wahl und ihren Grund. Eine Liste ist ein Menü, kein Plan — das Argument hier ist, den Plan fertig gebaut zu kaufen.