Entwicklungsplattformen: Wie wählt man je nach Produktphase aus?

## Evolution von Entwicklungsplattformen: Vom Prototyp zur Enterprise-Infrastruktur

Die Wahl der Entwicklungplattform muss zum Reifegrad des Produkts passen – andernfalls riskieren Sie technische, wirtschaftliche und organisatorische Engpässe. Dieser Artikel verwendet das Beispiel einer SaaS-Plattform für Dokumentenautomatisierung, die sich von MVP zu einer skalierbaren Enterprise-Lösung entwickelt.

Phase 1: Hypothesenvalidierung — Geschwindigkeit geht vor

Beim Produktstart ist die Geschwindigkeit der Ideenvalidierung entscheidend. Low-Code/No-Code-Plattformen wie Replit oder Lovable sind hier ideal: Sie ermöglichen es, in wenigen Tagen einen funktionsfähigen Prototyp zusammenzubauen, ohne tiefgehende Infrastrukturkenntnisse. Funktionsbeschreibung eingeben → Code erhalten → mit einem Klick deployen. Datenbank (oft Supabase) und Hosting sind out-of-the-box verfügbar.

Beispiel: In einem Monat – 600 Besucher, 50 Registrierungen, 10 aktive Kunden, MRR 500 $. Kosten – ca. 50 $/Monat. Der Schlüssel liegt darin, die Zahlungsbereitschaft zu bestätigen, nicht den Gewinn. Aber die Einschränkungen sind eingebaut: geteilte Infrastruktur, keine Isolation, kein horizontales Skalieren. Gut für MVP, aber ein Engpass beim Wachstum.

Phase 2: Wachstum — Skalierbarkeit und Kontrolle erforderlich

Bei steigender Last (z. B. 6.000 Dokumente pro Monat) reicht Replit nicht aus: CPU/RAM-Drosselung, Node.js-Event-Loop blockiert bei langen PDF-Parsing-Operationen. Sie brauchen asynchrone Queues, Retry-Logik, persistente Worker – fehlt in Basisumgebungen.

Lösung: Wechsel zu managed-runtime-Plattformen wie Vercel, Heroku, Fly.io, Deno Deploy, Dockerhost, Amvera. Sie bieten:

• Autoscaling
• CI/CD out of the box
• Preview-Umgebungen pro Branch
• CDN + Edge-Caching
• Built-in TLS

Mit Vercel können Sie Multi-Tenancy via organization_id hinzufügen – aber das häuft Tech Debt an: Eine fehlerhafte WHERE-Klausel = Datenlecks bei Kunden. Kosten steigen hier auf ~500 $/Monat, aber Skalierbarkeit und Entwicklergeschwindigkeit bleiben stabil.

Phase 3: Kontrolle — Infrastruktur wird wirtschaftlich relevant

Bei 200+ Kunden und MRR 6.000 $ können Infra-Kosten 40 % des Umsatzes fressen. Managed-Plattformen wie Vercel verbergen Komplexität, töten aber die Kontrolle: Kein VPC, WAF, SLA oder IP-Filtering. Enterprise-Kunden dulden das nicht.

Umkehrpunkt: Wechsel zu Cloud-Providern – VK Cloud, Yandex Cloud, Selectel – mit managed Services:

• Managed Kubernetes mit Autoscaling und Spot-Instances
• Isolierte VPCs und Security Groups
• Eigene Routing-Regeln und Network Policies
• Integration mit corporate IdPs via OIDC
• Konformität mit 152-FZ bei Hosting in der RF

Wirtschaftlich stabilisiert: Infra-Anteil sinkt auf 25 %. Bezahlen für tatsächliche Nutzung, nicht abstrakte Premiums. Aber Fehlkosten explodieren: Verpatzter Terraform oder K8s-Cluster kann alles lahmlegen.

Phase 4: Standardisierung — Internal Developer Platform für große Teams

IDPs lohnen sich ab >150 Entwicklern, einem Plattform-Team (~10 Personen) und 6–12 Monaten Investition. Es ist nun ein internes Produkt mit eigenem Roadmap, Golden Paths und Self-Service-Dev-Interfaces.

Beispiele:

• Backstage
• Humanitec
• VK Dev Platform
• Platform V Works
• «Withfera»
• «Marlin»

Die meisten Unternehmen bauen IDPs in-house – Prozesse sind zu spezifisch. Für Teams unter 30 ist es verfrüht: Wartungskosten überwiegen die Vorteile.

Was zählt

• Geschwindigkeit beim Start — nutzen Sie No-Code/Low-Code, um Hypothesen schnell zu validieren.
• Wechsel zu managed-runtime — essenziell für wachsende Lasten und asynchrone Tasks.
• Cloud statt PaaS — wenn Infra Gewinne frisst und Enterprise-Garantien gefragt sind.
• IDP — nicht für jeden — nur große Teams mit reifen Prozessen.
• Fehlkosten steigen — höhere Phasen bedeuten teurere Fehlkonfigurationen.

Typische Pain Points bei späten Übergängen

• Terraform-Repo, das nur eine Person kennt – und die ist im Urlaub.
• K8s-Cluster aus einem Tutorial: „Funktioniert, solange man es nicht anhaucht.“
• Neuer Dev kann lokale Env nicht in einem Tag hochfahren.
• Deploys passieren, aber keine Deploy-Standards.

Größtes Risiko: An einem Tool kleben, nachdem es überlebt ist. Der Sprung von PaaS zu Cloud ist tückisch: Produkt wächst es aus, aber Migrations-Know-how und Budget hinken nach.

— Editorial Team