Und warum „Infra fixen wir später“ leise die Velocity tötet.
Die meisten Startups schieben DevOps aus einem einfachen Grund auf: Es erzeugt keine Features. Das klingt rational und ist falsch — denn DevOps ging nie um Server, Tools oder YAML-Dateien. Es geht darum, wie schnell und sicher ein Team Entscheidungen in Realität umsetzen kann. Startups, die es aufschieben, sparen keine Zeit; sie häufen Execution Debt an, und wie technische Schulden kompoundet es — du zahlst es später mit Zinsen zurück, meist im denkbar schlechtesten Moment. Dieser Artikel handelt davon, warum der Aufschiebe-Instinkt verkehrt ist, was Aufschieben wirklich kostet und was „frühes DevOps“ tatsächlich bedeutet (viel weniger, als Founder fürchten).
Der Kern-Mythos: „DevOps ist für Scale, nicht für MVPs“
Die verbreitete Annahme: DevOps sei ein 100k-User-Problem — Infrastruktur zähle erst, wenn der Traffic wächst, und frühe Startups sollten „einfach manuell deployen“ und lean bleiben. In der Praxis stimmt das Gegenteil: Je früher die Phase, desto teurer sind DevOps-Fehler. Der Grund ist kontraintuitiv, aber einfach. DevOps senkt Kosten und Risiko jeder Änderung, und frühe Teams ändern ständig etwas — sie pivotieren, experimentieren, schreiben täglich um. Also ist die Phase mit den meisten Änderungen pro Woche die Phase, in der billige, sichere Änderungen den größten Hebel haben. DevOps aufzuschieben verschiebt nicht die Kosten; es legt Reibung auf genau die Phase, die am meisten davon abhängt, sich frei zu bewegen.
Es gibt hier eine nützliche empirische Linse. Das DORA-Forschungsprogramm reduziert Software-Delivery-Performance auf vier Maße — Deployment-Frequenz, Lead Time für Änderungen, Change Failure Rate und Time to Restore Service — und sein wiederkehrendes Ergebnis ist, dass die besten Teams gleichzeitig die schnellsten und die stabilsten sind. DevOps macht diese Kombination möglich, und sie ist für ein Drei-Personen-Team verfügbar, nicht nur für ein Enterprise.
Was passiert, wenn DevOps früh ignoriert wird
Die Konsequenzen sind konkret, und sie kommen schneller, als Founder erwarten.
Deployment wird schnell zum Bottleneck. Ohne DevOps-Basics sind Deploys manuell, Releases beängstigend, Rollbacks schmerzhaft, und „wer hat das deployed?“ ist eine echte Frage. Also passt sich das Team falsch an: Es bündelt Änderungen, vermeidet Releases, verzögert Fixes. Die Velocity fällt — nicht, weil die Engineers langsamer wurden, sondern weil Shippen riskant wurde, und ein rationales Team shippt weniger von etwas Riskantem. Die Ironie ist scharf: Das Ding wegzulassen, das „keine Features erzeugt“, macht es schwerer, Features zu liefern.
Bugs werden zu persönlichen Notfällen. In einem frühen Startup ohne Pipelines sind Founder on Call, Engineers debuggen in Production, und Fixes landen direkt auf main. Ohne Staging-Parität, ohne Rollback-Sicherheit, ohne Reproduzierbarkeit wird jeder Bug zur Feuerwehrübung. Das registriert sich im Moment selten als „Infrastruktur-Schuld“ — es registriert sich als Stress, als Adrenalin, als ein Team, das immer leicht in Flammen steht. Und es bleibt als strukturelles Problem unsichtbar, bis Menschen ausbrennen — dann hat die Kosten endlich einen Namen.
Environments driften, und niemand merkt es. Das klassische frühe Setup: Lokal „läuft“ es, Production verhält sich anders, Staging ist veraltet oder nicht existent. Das Ergebnis: Bugs, die nicht reproduzierbar sind, Fixes, die etwas anderes brechen, und ein allmählicher Vertrauensverlust ins Testen selbst. Das ist das Problem, das die Twelve-Factor-App-Methodik verhindern sollte — ihre Prinzipien von Dev/Prod-Parität und Konfiguration im Environment (nicht im Code) existieren genau dafür, dass „läuft auf meiner Maschine“ aufhört, ein Satz zu sein, den irgendjemand sagt. DevOps geht hier nicht um Kubernetes; es geht um Environment-Konsistenz, und die ist überwiegend Disziplin, kein Tool.
Performance- und Kostenprobleme tauchen spät auf. Ohne frühe Observability bleiben langsame Endpoints unbemerkt, Background-Jobs stauen sich, und Cloud-Kosten kriechen still nach oben. Wenn jemand fragt „warum ist das langsam / teuer?“, ist das System schon verheddert genug, dass die Antwort eine Untersuchung braucht. Frühe Observability — selbst minimale — liefert die Sichtbarkeit, Feedback-Loops und das Kostenbewusstsein, um diese Dinge zu fangen, solange sie noch kleine Anpassungen sind und keine strukturellen Probleme.
Security-Schuld häuft sich unsichtbar an. Frühe Systeme haben oft kein Secrets-Management, geteilte Credentials, keinen Audit-Trail und keine Access-Boundaries. Es fühlt sich okay an — bis ein Kunde nach Security fragt, Enterprise-Sales auftauchen oder Compliance ins Spiel kommt, und dann muss alles auf einmal gefixt werden, unter Deal-Druck. (Gerade für deutsche Enterprise-Käufer ist das der Moment, in dem ein Deal stockt; siehe Software bauen, die deutsche Compliance überlebt.) Secrets im Repo und geteilte Admin-Logins sind an Tag 1 billig zu vermeiden und teuer unter Audit aufzulösen.
Was „frühes DevOps“ tatsächlich bedeutet
Das ist die entscheidende Klarstellung, denn das Wort jagt Foundern eine Komplexität ein, die sie nicht brauchen. Frühes DevOps ist nicht Kubernetes überall, Microservices oder schwerer Prozess. Es sind langweilige Fundamente — und das Langweilige ist das Feature. Das Ziel ist nicht Raffinesse; es ist, Risiko und Reibung aus dem Akt des Änderns zu nehmen, mit der geringsten Maschinerie, die das erreicht.
Die Fundamente, die Startups früh wirklich brauchen
Wiederholbare Deployments. Ein Befehl oder eine Pipeline, jedes Mal derselbe Prozess, keine Heldentaten. Allein dieses eine Ding vervielfacht die Velocity, weil es „ein Deploy“ von einem Ereignis, auf das sich das Team einstellt, in ein Nicht-Ereignis verwandelt, das es beiläufig erledigt.
Basis-CI/CD. Automatisierte Builds, Tests vor dem Deploy, klare Fehlersignale. Das entscheidende Reframing: CI/CD ist kein Scale-Tooling, es ist Confidence-Tooling. Es existiert, damit das Shippen einer Änderung nicht den Atem anhalten verlangt — und Confidence ist, was ein kleines Team schnell bewegen lässt, ohne Dinge zu brechen, die es nicht sehen kann.
Environment-Parität. Lokal ≈ Staging ≈ Production, mit Unterschieden in der Config, nicht im Code. Das verhindert ganze Bug-Klassen, bevor sie entstehen — die nicht-reproduzierbaren, die Tage fressen. Es ist der am meisten unterschätzte Punkt der Liste, weil sich seine Auszahlung unsichtbar zeigt: das Feuer, das nie ausbricht.
Observability ab Tag 1. Strukturierte Logs, Basis-Metriken, Error-Tracking. Du brauchst nicht den vollen Drei-Säulen-plus-Tracing-Stack, den ein skaliertes System braucht — aber du brauchst etwas Verlässliches, damit du, wenn sich Verhalten ändert, es von deinen Instrumenten erfährst statt von einer Nutzer-Beschwerde. Selbst minimale Instrumentierung, an die wichtigen Dinge gebunden, schlägt ein raffiniertes Setup, das niemand anschaut.
Leichtgewichtiges Infrastructure as Code. Infrastruktur, die versioniert, reviewbar und reversibel ist — sodass Änderungen dieselbe Prüfung durchlaufen wie Code und zurückgerollt werden können. Das ist, was „Snowflake-Server“ verhindert (Martin Fowlers Begriff für einen handgetunten, einzigartigen Server, den niemand reproduzieren kann): die Maschine, die aus Gründen läuft, an die sich niemand erinnert, und mit der Person stirbt, die sie konfiguriert hat. Ein wenig Terraform oder Äquivalent früh bedeutet, dass deine Infrastruktur ein reproduzierbares Artefakt ist, kein fragiles Erbstück.
Die falsche Ökonomie des Aufschiebens
Founder sagen sich wir investieren in DevOps, sobald wir Traction haben. Die tatsächliche Reihenfolge ist grausamer: Traction kommt, das System bricht darunter, das Team wird langsamer im Versuch, mitzuhalten, und die Rewrite-Gespräche beginnen — genau dann, wenn die Führung das Team beschleunigen sehen muss, nicht beim Feuerlöschen. DevOps verlangsamt Startups nicht. Sein Fehlen tut es, leise, indem es jede Änderung besteuert, bis das Team aufhört, sie frei zu machen. Der „machen wir später“-Plan liefert verlässlich genau die Kosten, die er vermeiden wollte, nur später und größer. (Das ist dieselbe verzögerte-Verlangsamung-Dynamik wie in warum Geschwindigkeit ohne Architektur eine Falle ist — Aufschieben ist die teuerste Form von Geschwindigkeit.)
Der Wendepunkt: wenn es schon zu spät ist
Die meisten Teams investieren endlich in DevOps, wenn Deploys schmerzhaft sind, Outages passieren, Kunden sich beschweren und Engineers begonnen haben, Änderungen leise zu widerstehen, weil Ändern gefährlich ist. Bis dahin sind die Fixes reaktiv, die Infrastruktur-Änderungen selbst riskant (du operierst jetzt an einem laufenden, fragilen System), und das Momentum ist bereits verloren. Frühes DevOps vermeidet diese Klippe gänzlich — nicht, indem es fortgeschrittener ist, sondern indem es da ist, bevor die Klippe existiert. Der billigste Zeitpunkt, das Sicherheitsnetz zu bauen, ist, bevor du es brauchst; der teuerste ist mitten im Fall.
Die Technical-Co-Founder-Perspektive
Starke Technical Co-Founder halten eine Idee klar: Geschwindigkeit geht nicht darum, schnell Code zu schreiben — es geht darum, sicher, wiederholbar und vorhersehbar zu shippen. Ein Team, das schnell Code schreibt, ihn aber nicht ohne Risiko deployen kann, ist nicht schnell; es ist nur beschäftigt oberhalb eines Bottlenecks. DevOps ist das System, das geschriebenen Code auf Abruf in geshippte, reversible, observable Realität verwandelt — also ist es der Teil von „Geschwindigkeit“, der tatsächlich kompoundet. (Die breitere Version davon — dass ein Produkt „was passiert, wenn“ beantworten muss, nicht nur „was“ — steht in Software zu bauen ist leicht, Systeme zu bauen nicht; zuverlässiges Deployment und Observability sind, wie ein System sich das Recht erwirbt, zu antworten.)
Der H-Studio-Ansatz: richtig dimensioniertes DevOps, früh
Wir bringen kein Enterprise-DevOps zu einem Fünf-Personen-Startup — das wäre seine eigene Art verfrühter Komplexität, die Scale-Probleme löst, die du nicht hast, auf Kosten der Agilität, die du hast. Wir bringen minimales CI/CD, das tatsächlich funktioniert, Infrastruktur passend zur aktuellen Produktphase, Observability mit Business-Impact (keine Vanity-Dashboards) und Fundamente, die ohne Rewrite mitwachsen können. Das Ziel ist DevOps, das mit dem Produkt wächst, statt später in Panik angeschraubt zu werden — richtig dimensioniert für heute, aber so strukturiert, dass die Entscheidungen von heute nicht die Migration von morgen werden.
Schlussgedanke
Startups scheitern nicht, weil ihnen Features fehlen. Sie scheitern, weil sie nicht zuverlässig shippen, Probleme nicht schnell fixen und ihre Execution nicht so schnell skalieren können wie ihre Ambitionen. DevOps ist kein Ops-Problem, das man abgibt und vergisst — es ist ein Founder-Produktivitätssystem, die Maschinerie, die bestimmt, wie schnell Entscheidungen Realität werden und wie sicher Realität sich ändern kann. Und wie die meisten kompoundenden Dinge gilt: Je früher du es baust, desto länger zahlt es sich aus — was genau der Grund ist, warum „machen wir später“ die eine Timeline ist, die nie Sinn ergibt.
Häufige Fragen
Ist DevOps für ein Early-Stage-Startup nicht Overkill?
Im Gegenteil — frühe Teams ändern ständig etwas, und DevOps senkt Kosten und Risiko jeder Änderung, also ist der Hebel früh am größten. „Frühes DevOps“ heißt nicht Kubernetes und Microservices; es heißt langweilige Fundamente: wiederholbare Deploys, Basis-CI/CD, Environment-Parität, etwas Observability, leichtgewichtiges Infrastructure as Code.
Was ist „Execution Debt“?
Dieselbe Idee wie technische Schulden, auf Delivery angewandt. DevOps wegzulassen lässt dich diese Woche schnell sein, macht aber leise jede künftige Änderung riskanter und langsamer — manuelle Deploys, driftende Environments, Production-Feuerwehr. Es kompoundet, und du zahlst es (oft als Rewrite oder Burnout) mit Zinsen zurück.
Verlangsamt uns die Investition in DevOps jetzt?
Nein — sein Fehlen tut es, indem es Shippen riskant genug macht, dass Teams Änderungen bündeln und verzögern. Die DORA-Forschung ist klar, dass die schnellsten Teams auch die stabilsten sind; CI/CD und wiederholbare Deploys sind Confidence-Tooling, das ein kleines Team schnell bewegen lässt, ohne zu brechen, was es nicht sehen kann.
Was sind die ersten Schritte mit dem größten Hebel?
Wiederholbare Ein-Befehl-/Pipeline-Deploys, Basis-CI mit Tests vor dem Deploy, Environment-Parität (Config statt Code), verlässliches Error-Tracking und ein paar Schlüssel-Metriken, sowie leichtgewichtiges IaC, damit Infrastruktur versioniert und reproduzierbar ist statt ein „Snowflake-Server“. Dieses Set verhindert die meisten frühen Feuerwehrübungen.
Wann ist es zu spät?
Wenn Deploys schon schmerzhaft sind, Outages passieren und Engineers Änderungen widerstehen, weil Ändern gefährlich ist. An diesem Punkt sind Fixes reaktiv und Infrastruktur-Änderungen selbst riskant. Frühes DevOps vermeidet die Klippe, indem es vor ihr existiert — der billigste Zeitpunkt, das Sicherheitsnetz zu bauen, ist, bevor du es brauchst.
Early-Stage DevOps Review
Wenn dein Team Änderungen bündelt, Releases vermeidet oder direkt in Production debuggt, zahlst du den Preis für verzögertes DevOps. Wir analysieren Deployment-Risiken und Bottlenecks, CI/CD-Baseline, Environment-Parity, Observability und Cost Visibility sowie Security-Quick-Wins.
Wir richten DevOps & Automation ein, das zu deiner Produktphase passt: minimales CI/CD, das funktioniert, Observability mit Business-Bezug und Fundamente, die ohne Rewrite mitwachsen. Für Backend-Architektur sorgen wir dafür, dass deine Infrastruktur schnelle Iteration unterstützt. Für Startup MVP Builds inkludieren wir DevOps-Fundamente von Tag 1, damit du kein Execution Debt aufbaust.
Redigiert und faktengeprüft von Anna Hartung.