Pre-Seed-, Seed- und Series-A-Teams kommen zu uns, wenn Geschwindigkeit nicht mehr die einzige Metrik ist. Wir bauen das produktionsreife Fundament, mit dem Sie zwei Jahre lang Features ausliefern — ohne architektonischen Rewrite.
Die meisten unserer SaaS-Engagements fallen in eine dieser vier Formen:
Wir passen, wenn:
Nicht passend, wenn Sie pre-Funding sind, eine Idee validieren oder ein Feature auf einer bestehenden Plattform bauen.
Wir haben genug Post-Seed-Rebuilds geliefert, um zu wissen, welche Entscheidungen Teams sechs Monate kosten und die Series A verzögern. Das sind die fünf, die wir am häufigsten sehen.
Vier Phasen, planbarer Takt, wöchentliche Demos. Nichts versteckt sich hinter einem 'Big Reveal' — Sie sehen Deployments ab Woche drei.
Wir kartieren das System, entscheiden das Mandantenmodell, fixieren das Datenmodell und schreiben ein einseitiges RFC, das Ihr und unser Team unterzeichnen.
API-Contracts, Auth- und Billing-Boundaries, Deployment-Topologie. Das Ergebnis ist eine baubare Spezifikation — vor dem ersten Production-Code von Ihrem CTO geprüft.
Vertikale Slices, wöchentliche Deployments hinter Feature-Flags. Kein Big-Bang-Launch — Ihr Team shippt parallel Produktfeatures.
Lasttest, SLO-Baseline, Runbooks, On-Call-Dokumentation. Wir übergeben das System an Ihre Engineers, nicht an einen Wartungsvertrag.
Das sind keine Logos an einer Wand. Jede Zeile ist ein Engagement: was kaputt war, als wir kamen, was wir geändert haben, und was geliefert wurde.
Startup-EngineeringEine Telegram-native Gaming-Plattform vor einem viralen Launch — das bestehende Backend hätte keine einzige Spitzenstunde überstanden.
Stateless Java-Worker, queue-basiertes Fan-Out, planbare horizontale Skalierung auf einer Managed-Postgres-Stufe.
Launch-Woche ohne Skalierungs-Incident geliefert; das Engineering-Team baute weiter Produkt statt Infrastruktur zu patchen.
Startup-EngineeringEine KI-getriebene B2B-Growth-Plattform mit Inferenzpfad im Anwendungscode verflochten — jede Modelländerung gefährdete das Produkt.
Inferenz hinter eine stabile API getrennt, GDPR-konformen Datenfluss mit EU-only Processing entworfen, Billing-Events von Produkt-Events entkoppelt.
EU-Kunden ohne Compliance-Rework onboarden; das Datenteam iteriert Modelle, ohne Produkt-Releases abzustimmen.
Startup-EngineeringEin Multi-Rollen-Marktplatz, in dem Creator, Brands und Agency-Operator jeweils isolierte Workspaces, Dashboards und Freigabe-Flows in einem Produkt brauchten.
Rollenbasierte Produktlogik, Per-Workspace-Datenisolation und strukturierte Kampagnen- und Content-Workflows von Tag eins in das System eingebaut, statt nachträglich.
Drei Operator-Personas nutzen dieselbe Plattform konfliktfrei; neue Rollentypen lassen sich hinzufügen, ohne das Access-Model neu zu bauen.
Startup-EngineeringEin SaaS-Site-Builder, bei dem alle veröffentlichten Kundensites dieselbe Render-Schicht teilten — eine laute Site degradierte alle anderen.
Per-Tenant-Render-Schicht, dedizierte Cache-Topologie, isolierte Build-Pipelines, sodass jeder Kunden-Deploy unabhängig bleibt.
Skalierung auf zahlende Kunden ohne Per-Customer-Ops-Aufwand; Neukunden-Onboarding belastet die On-Call-Rotation nicht.
Die Entscheidungen, die wir mit Ihrem Team im Architektur-Sprint diskutieren werden — und die Fragen, die Investoren und Acquirer später stellen.
Silo, Pool oder Bridge — jedes Modell tauscht Isolation gegen Betriebsaufwand. Die richtige Wahl hängt von regulierten Daten, erwarteter Tenant-Größe und der Frage ab, ob Sie je ein Single-Tenant-Deployment brauchen.
Nutzer gehören zu Organisationen, nicht umgekehrt. Workspace-Switching, Rollenhierarchien und (später) SCIM hängen davon ab, dass die Org/User/Role-Boundary von Tag eins an stimmt.
Tarifwechsel mitten im Zyklus, Usage-basierte Preise, Trial-Conversions und anteilige Upgrades stehen oder fallen mit der Metering-Boundary. Behandeln Sie Billing als eigene Domain, nicht als Feature-Flag.
Ausgehende Webhooks scheitern. Eingehende Integrationen rate-limiten. Idempotenz, Retries und Replay sind Infrastruktur, nicht Anwendungscode — das SaaS, das das richtig macht, verliert keine Kundendaten bei einem Partnerausfall.
EU-Hosting ist der einfache Teil. Schwieriger: Auskunftsersuchen, Sub-Processor-Liste, Löschpfade und vertragliche AVVs, die das Procurement Ihres Kunden Zeile für Zeile liest.
Per-Tenant-Metriken zählen mehr als Aggregate. Eine 99,9 %-Global-SLO kann einen einzelnen Kunden mit 10 % Fehlern verstecken — und der churnt zuerst.
Wenn Ihre Frage hier nicht steht, ist sie fast sicher das Erste, was wir in einem 30-Minuten-Call besprechen.
Andere Situation? Wir beantworten die echte Frage, nicht die Broschüren-Version.
Direkt fragen→Vom Architektur-Sprint bis zum stabilen Produktionssystem: typischerweise 12–20 Wochen für ein Seed-Stage-Produkt — abhängig davon, was bereits geliefert ist und was weiterlaufen muss. Der erste Deploy neuen Codes erfolgt meist in Woche drei. Wir quoten keine Re-Architektur ohne Architektur-Sprint-Output — Blindquoten ist, wie Teams verbrennen.
Ja — das ist die explizite Bedingung, um die wir planen. Jede Implementierungsphase produziert vertikale Slices hinter Feature-Flags, wöchentlich deployt. Ihr Produktteam arbeitet im selben Repo, reviewt dieselben PRs und liefert Features parallel zum Rebuild. Es gibt nie einen Production-Freeze.
Wir arbeiten daneben. Wir betten uns in Ihr Repository ein, folgen Ihrem Code-Review, gehen zu Ihren Standups, wenn es hilft. Unser Job ist, Ihre Engineers stärker zu machen, nicht abhängig. Am Ende der Stabilisierung läuft das System auf Ihrer On-Call-Rotation, nicht auf unserer.
Modularer Monolith — fast immer, bis Sie mindestens drei Produkt-Squads oder einen klaren operativen Grund zum Splitten haben. Microservices in der Seed-Phase tauschen ein echtes Problem (Code-Kopplung) gegen ein schlimmeres (operative Komplexität). Ausnahmen: alles, was unabhängig skalieren muss — KI-Inferenz, Per-Tenant-Rendering.
Default ist Bridge — Schema pro Mandant in einem geteilten Cluster — weil es am leichtesten zu migrieren ist. Silo und Pool sind beide vom Bridge aus erreichbar mit überschaubarem Aufwand; die Rückwege sind brutal. Die Entscheidung fällt im Architektur-Sprint anhand des größten erwarteten Mandanten und Ihrer regulatorischen Lage — nicht per Default.
GDPR ist Baseline, kein Feature. Jedes System, das wir liefern, hat EU-only Processing, eine dokumentierte Sub-Processor-Liste, Per-Tenant-Löschung, die Backups übersteht, und eine AVV-Vorlage, die Ihre Enterprise-Kunden unterzeichnen können. Wir over-engineern das lieber an Tag eins als sechs Monate später eine Halbmaßnahme dem Procurement zu erklären.
