Den Technologie-Stack für ein Schweizer SaaS wählen

Stack-Entscheidungen werden in einer Woche getroffen und ein Jahrzehnt lang getragen. Dieses Missverhältnis ist das ganze Problem, und die meisten Auswahlprozesse bilden es nicht ab.

Die Frage lautet nicht, welche Technologie die beste ist. Sie lautet, für welche Sie in drei Jahren noch Leute finden, welche Sie dann noch bezahlen und welche Sie noch wechseln können.

Drei Kriterien, die den technischen Vergleich schlagen

Finden Sie dafür Leute in der Schweiz? Ein Stack mit kleinem lokalem Bewerberkreis macht jede Besetzung langsamer und teurer — in einem Markt, in dem die Rekrutierung ohnehin der Engpass ist. Das wiegt hier schwerer als in grösseren Märkten: Eine Vorliebe, die in einem grossen europäischen Tech-Zentrum vertretbar ist, kann im Schweizer Markt eine ernsthafte Einschränkung sein.

Was kostet der Betrieb bei zehnfacher Last? Manche Architekturen skalieren linear in den Kosten, manche nicht. Der Unterschied zeigt sich im Prototyp nicht und dominiert im dritten Jahr.

Wie schwer ist der Ausstieg? Jeder Stack erzeugt Bindung. Die Frage ist, ob sie auf Ebene einer Bibliothek liegt (Wochen zum Ersetzen) oder auf Ebene des Datenmodells (Neubau).

Gewinnt eine Technologie im Benchmark und verliert bei allen drei Punkten, verliert sie.

Die Bausteine und was jeweils wirklich zählt

Sprachen und Frameworks

Für die meisten Schweizer SaaS-Produkte lautet die ehrliche Antwort, dass die gängigen Optionen alle genügen — und dass das Ökosystem unterscheidet, nicht die Sprache.

Was zu gewichten ist:

• Der lokale Bewerberkreis — das stärkste Kriterium und das am häufigsten zugunsten technischer Vorlieben übergangene
• Bibliotheksreife für Ihre Domäne — Zahlungen, Dokumentenverarbeitung, was Ihr Produkt tatsächlich tut
• Langfristiger Support — wie lange wird eine Version unterstützt, und was kostet ein Wechsel?

Was weniger zählt: Leistungsvergleiche. Sehr wenige SaaS-Produkte werden durch die Ausführungsgeschwindigkeit der Sprache begrenzt; begrenzt werden sie durch Datenbankentwurf und Netzwerkaufrufe.

Backend as a Service

Verwaltete Backends beschleunigen die ersten sechs Monate tatsächlich. Der Kompromiss zeigt sich später und an einer vorhersehbaren Stelle.

Einsetzen, wenn: Sie ein Produkt validieren, das Team klein ist und das Datenmodell einfach.

Vorsicht, wenn: Ihre Daten unter revDSG- oder DSGVO-Einschränkungen fallen und der Dienst in einer Rechtsordnung verarbeitet, die Sie nicht akzeptieren können — oder wenn Ihre Zugriffsmuster ungewöhnlich werden und Sie gegen die Plattform arbeiten statt mit ihr.

Die Frage, die früh gehört: Wenn wir diesen Dienst verlassen müssten — was würden wir neu schreiben, die Integrationsschicht oder das Datenmodell? Das Erste ist ein Projekt, das Zweite ein Neubau.

Low-Code-Plattformen

Low-Code hat einen realen und engen Platz: interne Werkzeuge, Verwaltungsoberflächen, Abläufe, die sich oft ändern und von wenigen genutzt werden.

Schief geht es beim Produkt mit Kundenkontakt. Die ersten 80 Prozent gehen schnell, bei den letzten 20 Prozent gehen die Annahmen der Plattform und Ihre Anforderungen auseinander — und der Notausgang ist meist ein Neubau in dem Stack, den Sie übersprungen haben.

Eine brauchbare Regel: Low-Code für das, was das Produkt stützt; konventioneller Code für das Produkt selbst.

Open Source

Open Source ist für die meisten Bausteine die Voreinstellung — und nicht kostenlos. Die Kosten sind real und beherrschbar, wenn man sie benennt:

• Pflege. Jemand muss Versionen und Sicherheitshinweise verfolgen. Verantwortet das niemand, merken Sie die Lücke bei einem Vorfall.
• Lizenzen. Copyleft-Bedingungen sind für ein kommerzielles SaaS-Produkt relevant. Das ist eine rechtliche Prüfung, keine Entwicklervorliebe — und vor der Einführung viel günstiger.
• Projektgesundheit. Commit-Frequenz, Zahl der Maintainer, Release-Takt. Eine von einer Person gepflegte Abhängigkeit ist ein Risiko mit Namen.

Schweiz-spezifische Einschränkungen

Drei, die die engere Auswahl verändern und nicht nur Arbeit hinzufügen.

Datenstandort und Zugriff. Nach revDSG/nDSG und DSGVO müssen Sie wissen, wo Daten liegen und wer sie erreichen kann. Das schränkt verwaltete Dienste stärker ein als selbst betriebene Bausteine, und es wird von der Architektur entschieden, nicht von der Konfiguration. Klären Sie es vor der Wahl.

Fragen aus der Beschaffung. Wenn Sie an Schweizer oder deutsche Unternehmen verkaufen, rechnen Sie mit Fragen zu Unterauftragsverarbeitern, Datenstandort, Ausstiegspfaden und Zertifizierungen. Ein Stack auf einer langen Kette fremder Dienste macht diese Fragen schwerer beantwortbar — und eine langsame Antwort kostet Aufträge.

Währung und Kostenplanbarkeit. Nutzungsabhängig bepreiste Dienste bringen Schwankung in eine Kostenbasis, die eine Schweizer Finanzleitung lieber plant. Kein Hindernis, aber es verdient eine bewusste Antwort statt einer Überraschung.

Eine funktionierende Entscheidungsreihenfolge

1. Zuerst die Einschränkungen aufschreiben — Datenstandort, Rekrutierungsrealität, erwartete Grösse, Ausstiegsanforderungen
2. Alles ausscheiden, was eine Einschränkung verletzt. Das entfernt meist mehr Optionen als der technische Vergleich.
3. Den Rest nach Ökosystem und Rekrutierbarkeit vergleichen, nicht nach Benchmarks
4. Die riskanteste Integration prototypisieren, nicht die einfachste Funktion
5. Aufschreiben, was die Entscheidung ändern würde — und zu diesem Zeitpunkt erneut prüfen

Schritt 5 wird selten gemacht und macht die Entscheidung erst umkehrbar. Eine mit ihren Annahmen festgehaltene Stack-Wahl lässt sich neu prüfen, wenn sich die Annahmen ändern; eine als Schlussfolgerung festgehaltene wird stillschweigend endgültig.

Weiterführend

• Standardsoftware am Limit: Selbst bauen oder kaufen?
• Tech-Teams in der Schweiz ohne Verzögerung skalieren
• Softwareentwicklung

Wenn Sie vor dieser Entscheidung stehen und sie geprüft haben möchten, vereinbaren Sie ein Gespräch. Unverbindlich.