Den Tech-Stack für Ihr erstes SaaS wählen: ein ehrlicher Leitfaden für Gründer

Fragen Sie zehn Entwickler, welchen Tech-Stack Sie für Ihr erstes SaaS verwenden sollen, und Sie erhalten fünfzehn Antworten, drei davon mit der Überzeugung einer Religion vorgetragen. Die meisten dieser Antworten sind richtig – für die Person, die sie gibt. Keine davon handelt von Ihnen, Ihrem finanziellen Spielraum oder den Kundinnen und Kunden, die Sie noch nicht gewonnen haben. Wenn Sie als Gründerin oder Gründer vor dieser Entscheidung sitzen und sich leicht unwohl fühlen, hier ist, was niemand laut ausspricht: Der Stack zählt weit weniger, als man Ihnen glauben machen will, und die wenigen Punkte, in denen er zählt, sind nicht die, über die online gestritten wird.

Ich habe etliche Erstgründer dabei begleitet, von einer Folienpräsentation zu einem Produkt zu kommen, für das echte Menschen bezahlen. Fast keiner von ihnen war technisch versiert. Fast alle kamen an, nachdem sie bereits eine beängstigende Menge an Stack-Folklore aufgesogen hatten – dass sie Microservices brauchten, dass ein Framework "tot" sei, dass eine falsche Wahl sie ruinieren würde. Und fast jedes Mal erwies sich der Stack als eine der unbedeutendsten Entscheidungen, die sie in jenem Jahr trafen. Was Projekte tötete, waren der Umfang, unklare Verantwortlichkeiten und das schöne Bauen des Falschen. Niemals das Framework.

Das ist also der Leitfaden, den ich diesen Gründern gebe, bevor wir eine einzige Zeile Code schreiben. Er wird Ihnen nicht sagen, dass Sie einen bestimmten Stack verwenden sollen, denn wer das verspricht, ohne Ihr Geschäft zu kennen, verkauft etwas. Stattdessen gibt er Ihnen eine Denkweise an die Hand – damit Sie, was auch immer Sie wählen oder Ihr Team vorschlägt, es wie ein erwachsener Mensch auf Plausibilität prüfen können, statt nervös zu nicken.

Warum sich diese Entscheidung schwerer anfühlt, als sie ist

Die Stack-Frage fühlt sich riesig an, weil sie die erste scheinbar unumkehrbare Wahl ist, die Sie treffen, und weil sie in eine Sprache gehüllt ist, die Sie nicht sprechen. Begriffe wie Postgres, React, Kubernetes, serverless werden herumgeworfen, als wäre die Wahl dazwischen wie die Wahl des Fundaments eines Gebäudes – ein Fehler, und das Ganze stürzt ein.

Aber Software ist kein Gebäude. Sie gleicht viel eher einer Küche, die man umbauen kann, während man noch kocht. Erfolgreiche Unternehmen schreiben ständig Teile ihres Stacks neu; die Version eines Produkts, die seine ersten hundert Kunden findet, ist fast nie die Version, die seine ersten hunderttausend bedient. Das Ziel Ihres ersten Stacks ist nicht, ewig zu halten. Es ist, Ihnen zu erlauben, schnell genug zu bauen, zu ändern und auszuliefern, um herauszufinden, ob das überhaupt jemand will. Das ist eine völlig andere – und viel niedrigere – Hürde als "perfekt für das nächste Jahrzehnt".

Sobald Sie das akzeptieren, halbiert sich der Druck. Sie versuchen nicht mehr, die Zukunft vorherzusagen. Sie versuchen, eine vernünftige, umkehrbare Wette zu platzieren, die Sie zu einem funktionierenden Produkt und zahlenden Nutzern bringt. Und vernünftige Wetten kann eine nicht-technische Gründerin oder ein nicht-technischer Gründer absolut beurteilen.

Was ein "Stack" eigentlich ist, einfach erklärt

Bevor Sie irgendetwas entscheiden, hilft es, das Wort zu entmystifizieren. Ein Tech-Stack ist einfach die Sammlung von Werkzeugen, mit denen Ihre Software gebaut und betrieben wird. Sie können ihn sich in vier Schichten vorstellen, und Sie müssen keine davon tiefgehend verstehen – Sie müssen nur wissen, dass es sie gibt.

• Das Frontend – das, was Nutzer in ihrem Browser oder ihrer App sehen und anklicken. Das ist der Teil, an dem alle Sie messen.
• Das Backend – die Logik und die Regeln, die auf einem Server laufen: wer was darf, was passiert, wenn er es tut, wie Geld fließt.
• Die Datenbank – wo Ihre Informationen tatsächlich liegen: Nutzer, Bestellungen, Abonnements, alles, dessen Verlust Sie am Boden zerstören würde.
• Die Infrastruktur – die Server und Dienste, die all das oben Genannte online, gesichert und um 3 Uhr nachts erreichbar halten.

Wenn jemand sagt "wir nehmen einen modernen JavaScript-Stack" oder "Rails auf Postgres", beschreibt er Entscheidungen über diese vier Schichten hinweg. Mehr nicht. Jedes SaaS, vom Zwei-Personen-Nebenprojekt bis zum börsennotierten Unternehmen, ist irgendeine Version dieser vier zusammengestapelten Dinge. Die großspurig klingenden Architekturdiagramme sind genau das, nur mit mehr Kästchen gezeichnet.

Was wirklich zählt (und was nicht)

Hier geht der meiste Stack-Rat in die Irre: Er optimiert auf Dinge, die Ihre ersten beiden Jahre nicht beeinflussen, und ignoriert die Dinge, die es tun. Lassen Sie mich bei beiden Listen deutlich werden.

Was wirklich zählt

Wer es bauen und warten kann. Der mit Abstand größte Faktor ist nicht die Technologie – es sind die Menschen. Der beste Stack für Sie ist der, in dem Ihr Team (oder der Partner, den Sie engagieren) heute tatsächlich fließend arbeiten kann. Ein "perfekter" Stack, den nur eine seltene Spezialistin oder ein seltener Spezialist versteht, ist eine schlechtere Wahl als ein langweiliger, den jede kompetente Entwicklerin oder jeder kompetente Entwickler aufgreifen kann. Einstellbarkeit und Kontinuität schlagen theoretische Eleganz jedes Mal.

Wie schnell Sie Dinge ändern können. Anfangs werden Sie sich über Ihr Produkt ständig irren. Die eigentliche Aufgabe des Stacks ist es, das Umdenken billig zu machen. Ausgereifte, gut dokumentierte Werkzeuge mit großen Communities lassen Sie schnell vorankommen, weil Antworten auf Ihre Probleme bereits existieren. Bleeding-Edge-Werkzeuge machen Sie zu der Person, die die Fehler entdeckt.

Ob Sie dafür einstellen können. Wählen Sie etwas Obskures, und Sie binden Ihre Zukunft an die Person, die es gebaut hat. Wählen Sie etwas Verbreitetes und Langweiliges, und Sie finden immer die nächste Entwicklerin, die nächste Agentur, die nächste Person zur Übernahme. Langweilig ist ein Vorteil, wenn Ihr Geschäft davon abhängt.

Was weit weniger zählt, als man sagt

Reine Performance und "Skalierung". Sie haben kein Skalierungsproblem. Sie haben ein Niemand-nutzt-es-noch-Problem, was das gegenteilige Problem ist. Architekturen, die für Millionen von Nutzern ausgelegt sind, bremsen Sie aus, wenn Sie elf haben. Die berühmten Unternehmen, die Sie nachahmen, bauten zuerst die einfache Version und bauten sie später neu, finanziert durch den Erfolg. So sollten Sie es auch tun.

Welches bestimmte Framework dieses Jahr "gewinnt". Frameworks steigen und fallen in einem Modezyklus, der fast nichts damit zu tun hat, ob sie Ihr Rechnungs-SaaS gut bauen. Jede der gängigen, weit verbreiteten Optionen erledigt die Aufgabe. Der Trend ist Rauschen; wählen Sie aus der langweiligen, beliebten Mitte und machen Sie weiter.

Warum "langweilige" Technologie meist gewinnt

Es gibt eine stille Weisheit unter erfahrenen Entwicklern, die Neulinge enttäuschend finden: Die beste Technologie für ein neues Geschäft ist meist die langweilige, bewährte, leicht unmoderne Sorte. Nicht weil neue Werkzeuge schlecht sind, sondern weil jede Entscheidung, die Sie treffen, ein begrenztes Budget an Neuartigkeit ausgibt – die Anzahl der unvertrauten, unsupporteten, überraschenden Dinge, die Ihr kleines Team auf einmal bewältigen kann.

Geben Sie dieses Budget für das aus, was Ihr Geschäft besonders macht – das eigentliche Produkt, die Erkenntnis, die nur Sie haben. Geben Sie es nicht für eine Datenbank aus, von der niemand gehört hat, nur um sich modern zu fühlen. Ein langweiliger, ausgereifter Stack bedeutet, dass Probleme schon gelöst wurden, Dokumentation existiert, das Einstellen leicht ist und das Werkzeug nicht nächstes Jahr verschwindet, wenn sein einziger Maintainer das Interesse verliert. Langweilig lässt Sie all Ihre Begeisterung dorthin lenken, wo sie sich auszahlt: in die Kundschaft.

Hier verändert KI das Bild ein wenig – und nicht so, wie der Hype suggeriert. KI-Programmierassistenten sind bei langweiligen, beliebten Technologien dramatisch besser, weil sie auf einem Jahrzehnt öffentlicher Antworten dazu trainiert wurden. Wählen Sie einen gängigen Stack, und Ihr Team (und Ihre Werkzeuge) bekommen schnellere Hilfe geschenkt. Wählen Sie etwas Exotisches, und Sie sind genau dann auf sich allein gestellt, wenn Sie es sich am wenigsten leisten können.

Eine Entscheidungsmethode, die Sie tatsächlich nutzen können

Genug der Prinzipien. Hier ist ein konkreter Weg, zu einer Entscheidung zu kommen, ob Sie nun selbst wählen, eine freiberufliche Kraft briefen oder bewerten, was eine Agentur vorschlägt. Nichts davon verlangt von Ihnen, Code zu schreiben – nur die richtigen Dinge zu fragen und die Antworten abzuwägen.

1. 1
   Beginnen Sie beim Team, nicht bei der Technik

   Fragen Sie: Wer baut und wartet das in den nächsten zwei Jahren? Was diese Personen bereits gut beherrschen, ist Ihr starker Standard. Den Stack zu wechseln, um einem Trend nachzujagen, schlägt selten die Routine.
2. 2
   Standardmäßig gängig und bewährt

   Wählen Sie aus der beliebten, gut dokumentierten Mitte jeder Schicht. Wenn Sie für ein Werkzeug nicht schnell Tutorials, Stellen und große Communities finden, werten Sie das als Warnung, nicht als Vorteil.
3. 3
   Auf Veränderung optimieren, nicht auf Skalierung

   Bevorzugen Sie die Wahl, die das Bearbeiten Ihres Produkts billig und schnell macht. Sie werden sich über das Produkt immer wieder irren – die Aufgabe des Stacks ist es, das Irren überlebbar zu machen.
4. 4
   Halten Sie die Architektur so einfach wie möglich

   Eine Datenbank. Ein Backend. Ein Frontend. Keine Microservices, kein cleveres verteiltes Irgendwas, bis ein echtes, gemessenes Problem Sie dazu zwingt. Einfachheit ist das Ziel, nicht der Kompromiss.
5. 5
   Halten Sie schriftlich fest, warum Sie sich entschieden haben

   Ein Absatz: wer es baut, was Sie gewählt haben und was sich ändern müsste, damit Sie es überdenken. Diese Notiz erspart Ihnen, die Entscheidung jedes Mal neu zu verhandeln, wenn jemand eine steile These liest.

Wenn Sie sonst nichts befolgen, befolgen Sie Schritt eins und vier. Bauen Sie mit den Menschen, die Sie haben, auf der einfachsten Architektur, die funktioniert. Diese Kombination umgeht stillschweigend die beiden Fehlermodi, die die meisten ersten SaaS-Produkte versenken: niemand, der es warten kann, und ein System, das für seine Größe zu kompliziert ist.

Fragen an alle, die einen Stack vorschlagen

Die meisten Gründer wählen den Stack nicht allein – eine Entwicklerin, eine Agentur oder ein CTO-Freund schlägt einen vor. Sie müssen die Technologie nicht selbst prüfen. Sie müssen eine Handvoll Fragen stellen und darauf hören, wie sie beantwortet werden. Selbstsichere Antworten in klarer Sprache sind ein gutes Zeichen. Defensiver Jargon ist es nicht.

• "Warum dieser und nicht die langweilige beliebte Option?" – eine gute Antwort dreht sich um Ihre konkreten Bedürfnisse, nicht um das, was gerade angesagt ist.
• "Wenn Sie von einem Bus überfahren würden, wie leicht könnte jemand anderes das übernehmen?" – die Antwort verrät, wie selten und riskant die Wahl ist.
• "Was ist die einfachste Version dieser Architektur, die noch funktioniert?" – achten Sie darauf, ob die Person zur Einfachheit greift oder zur Komplexität.
• "Wie leicht wird es sein, die nächste Entwicklerin oder den nächsten Entwickler dafür einzustellen?" – verbreitete Fähigkeiten bedeuten einen gesunden Markt; exotische bedeuten Abhängigkeit.
• "Was passiert, wenn wir in drei Monaten eine Kernfunktion ändern müssen?" – Sie wollen hören, dass Änderung billig ist, nicht gefürchtet.

Häufige Fallen, die wie gute Ideen aussehen

Ein paar Muster kommen so oft vor, dass es sich lohnt, sie zu benennen, denn jedes fühlt sich im Moment verantwortungsvoll an und kostet Sie später teuer.

Für eine Skalierung bauen, die Sie nicht haben. Der Drang, es "richtig zu machen", verleitet Gründer dazu, für Millionen von Nutzern zu architekturieren, bevor sie zehn haben. Jedes Stück dieser Zukunftssicherung ist Komplexität, die Sie jetzt bezahlen, in Zeit und Geld, um ein Problem zu lösen, das vielleicht nie eintritt. Bauen Sie für die nächsten hundert Nutzer. Re-architekturieren Sie, wenn Wachstum es nötig macht – und lassen Sie es ein erfreuliches Problem sein.

Dem Neuesten hinterherjagen. Ein glänzendes Framework, das letzten Monat erschien, hat keine Erfolgsbilanz, dünne Dokumentation und eine winzige Community. Sie verbringen Ihre Nächte mit dem Debuggen des Werkzeugs, statt Ihr Produkt zu bauen. Lassen Sie andere die frühen Anwender sein; Sie haben ein Geschäft auszuliefern.

An die billigste Stelle auslagern, auf was auch immer sie bevorzugt. Das niedrigste Angebot kommt oft mit einem obskuren Stack, den nur dieses eine Team kennt. An dem Tag, an dem Sie sich trennen, wird Ihr Produkt zu einer Insel, die niemand sonst erreicht. Vorne billig, hinten ruinös. Bestehen Sie auf gängiger, einstellbarer Technologie, auch wenn Sie auslagern – gerade wenn Sie auslagern.

Wann es wirklich Zeit ist, Ihren Stack zu überdenken

Nichts davon bedeutet "nie ändern". Es bedeutet, aus echten Gründen zu ändern, gemessen, nicht eingebildet. Sie werden wissen, dass es wirklich Zeit ist, Ihren Stack weiterzuentwickeln, wenn konkrete Signale auftauchen – nicht, wenn ein Blogbeitrag Sie ängstlich macht.

Beachten Sie das Muster: Echte Gründe drehen sich um gemessenen Schmerz in Ihrem tatsächlichen Geschäft. Falsche Gründe drehen sich um Mode, Vergleich und Ruhelosigkeit. Wenn ein echtes Signal auftaucht, ändern Sie ein Stück nach dem anderen – nicht den ganzen Stack in einem heroischen Neuschreiben, das alles für sechs Monate lahmlegt. Evolution, nicht Revolution.

Häufige Fragen