Warum jedes MVP bei uns auf einer Boilerplate startet

Fast jedes Produkt, das wir bei FeatherFlow bauen, braucht in der ersten Woche dieselben Dinge. Leute müssen sich registrieren und einloggen. Jemand muss bezahlen. Die App muss E-Mails verschicken: eine Willkommensmail, einen Passwort-Reset, eine Rechnung. Nichts davon macht ein Produkt besonders. Aber alles muss funktionieren, und alles kostet Zeit.

Deshalb fangen wir nicht mit einem leeren Ordner an, sondern mit einer Boilerplate: einem Startprojekt, in dem diese Teile schon gebaut und miteinander verbunden sind.

Was „gelöstes Problem“ wirklich heißt

Login klingt einfach, bis man ihn richtig baut. Passwort vergessen, E-Mail bestätigen, Login mit Google, Sessions, die ablaufen, jemand, der sich zweimal mit derselben Adresse anmeldet. Jedes Teil ist klein. Zusammen sind es Tage.

Bei Zahlungen ist es genauso. Ein Abo mit Stripe ist nicht nur ein „Jetzt bezahlen“-Button. Das meiste passiert später im Hintergrund: eine Verlängerung, eine abgelehnte Karte, eine Testphase, die endet, eine Kündigung. Stripe meldet das deiner App über Webhooks, und laut Stripes eigener Doku muss eine Abo-Integration diese Ereignisse verarbeiten, weil fast alles bei Abos asynchron passiert. Wenn das schiefgeht, behalten Leute ihren Zugang, obwohl sie nicht mehr zahlen. Oder sie verlieren ihn, obwohl sie zahlen. Beides ist schlecht.

Eine gute Boilerplate hat das alles schon hinter sich. Jemand anderes hat die Sonderfälle gefunden, und wir müssen sie nicht noch mal auf Kosten eines Kunden finden.

Wohin die gesparten Wochen gehen

Es geht nicht darum, weniger zu arbeiten. Es geht darum, die Zeit dort einzusetzen, wo sich entscheidet, ob das Produkt funktioniert:

• Das Kernfeature. Das eine, wofür Nutzer kommen. Hier wollen wir unsere beste Denkarbeit.
• Früh mit Nutzern reden. Wenn Login und Bezahlung laufen, können wir echten Leuten früher ein echtes Produkt zeigen.
• Feinschliff, wo er zählt. Onboarding, leere Zustände, die ersten fünf Minuten. Da entscheiden Leute, ob sie bleiben.

Die ehrlichen Nachteile

Eine Boilerplate ist kein Geschenk. Darauf achten wir inzwischen:

• Du übernimmst fremde Entscheidungen. Datenbank, Framework, Ordnerstruktur. Wenn das Kit eine Datenbank nutzt, die du nicht willst, kostet der Wechsel später echte Arbeit. Wir wählen den Starter nach dem Stack, den wir sowieso nehmen würden.
• Du musst ihn trotzdem verstehen. Code, den du nicht geschrieben hast, musst du trotzdem debuggen. Bevor eine Boilerplate in ein Kundenprojekt geht, liest jemand aus dem Team den Auth- und Billing-Teil durch.
• Kits altern. Abhängigkeiten ändern sich schnell. Ein Starter, der seit einem Jahr nicht aktualisiert wurde, kann mehr kosten, als er spart.
• Alles sieht gleich aus. Die Standard-Landingpage fliegt bei uns als Erstes raus.

Wie man eine auswählt

Genau deshalb habe ich BoilerplateHub gestartet, ein Verzeichnis, in dem man Starter nach Stack und Features vergleichen kann. Meine kurze Checkliste:

1. Nutzt sie den Stack, den du sowieso nehmen würdest?
2. Wird sie aktiv gepflegt? Schau dir die letzten Updates an.
3. Lies den Auth- und Payment-Code, bevor du kaufst. Wenn du ihm nicht folgen kannst, ist das ein Warnzeichen.
4. Prüf die Lizenz, vor allem wenn du für Kunden baust.

Eine Boilerplate macht dein Produkt nicht gut. Sie räumt nur den Weg frei, damit der schwierige und spannende Teil die Zeit bekommt, die er verdient.