Hör auf, AWS zu benutzen.

Wie oft hast du schon gesehen, wie jemand ein MVP mit allen Cloud-Glocken und -Pfeifen baut, nur um dann zuzusehen, wie es nirgendwohin führt?

Das Produkt hatte Lambda-Funktionen. API Gateway. Cognito. S3, CloudFront, DynamoDB, CloudWatch, IAM-Policies und noch mehr. Das Architekturdiagramm sah aus wie eine U-Bahn-Karte. Und trotzdem… hat es niemand genutzt.

Die Wahrheit ist einfach: Du brauchst kein AWS, um etwas zu bauen, das Nutzer lieben.

Das Overkill-Problem

Es gibt eine Falle, in die viele tappen. Du liest ein paar Blogposts oder siehst ein Diagramm auf Twitter und denkst plötzlich, dein kleines Projekt bräuchte die gleiche Architektur wie Netflix.

Tut es nicht.

Die meisten Early-Stage-Projekte sterben nicht, weil ihnen Scalability fehlt, sondern weil ihnen Nutzer fehlen. Oder weil das Produkt verwirrend, buggy war oder kein echtes Problem löst.

Wenn du deine Infrastruktur über-engineerst, verschwendest du nur Zeit, brennst aus oder bringst es vielleicht nie an den Start.

Was du wirklich brauchst

Wenn du solo unterwegs bist oder in einem kleinen Team etwas Nützliches bauen und ausliefern willst, reicht meistens Folgendes:

• Ein VPS für 5 € bis 20 € im Monat – z. B. bei Hetzner, DigitalOcean oder ähnlichen Anbietern
• Docker Compose, um deine App und eine Datenbank laufen zu lassen
• Eine managed Container-Plattform wie Sliplane (ja, als Gründer bin ich biased), wenn du Server-Management komplett umgehen willst

Du brauchst kein Kubernetes. Musst dir keine Gedanken über Auto-Scaling machen. Du musst nicht sechs AWS-Services verbinden, nur um eine einzige Seite anzuzeigen.

Die meisten Indie-Produkte laufen auf einem einzigen Server lange Zeit problemlos.

Wann AWS Sinn macht

Seien wir ehrlich: Es gibt Situationen, in denen AWS die richtige Wahl ist:

• Du willst AWS lernen, weil du einen Job suchst oder deine Cloud-Skills ausbauen möchtest
• Du hast sehr spezielle Anforderungen, z. B. Daten, die in einer staatlichen Cloud liegen müssen, oder du musst nahe an einer Kunden-Infrastruktur sein, die ebenfalls auf AWS läuft
• Du läufst ein Problem an, das von Tag 1 an global skalieren muss
• Du steckst schon tief im AWS-Ökosystem und hast viel Expertise

Das sind legitime Gründe. Aber sei ehrlich zu dir: Die meisten Projekte starten nicht so.

Und selbst wenn du später doch AWS brauchst, ist das kein Drama. Du kannst jederzeit migrieren, wenn die Zeit reif ist. Dann hast du hoffentlich Umsatz, Nutzer und einen klaren Plan, was du wirklich brauchst.

Denk dran:
Dein Produkt scheitert viel eher daran, was es tut, als daran, wo es läuft.

Wie du ohne AWS loslegst

Willst du schnell etwas launchen, ohne Wochen in Cloud-Architektur zu investieren? Hier ein solider Start:

• Definiere App, Datenbank und Background-Worker mit Docker Compose
• Deploy auf einen VPS per SSH und docker compose up
• Oder nutze eine Plattform, die dir das Ops abnimmt, damit du dich aufs Coden konzentrieren kannst
• Greif auf Open-Source-Tools zurück für Monitoring, Auth oder Task Queues

Fertig. Von null auf live in einem Nachmittag. Keine Zertifizierung nötig.

Zum Abschluss

Du brauchst kein AWS, um etwas Großartiges zu bauen. Was du brauchst, ist Fokus, ein funktionierendes Produkt und die Fähigkeit, schnell zu releasen. Eine fette Infrastruktur rettet kein schlechtes Produkt. Eine simple Infrastruktur tötet kein gutes.

Starte klein. Launch early. Lern schnell. Skalieren kannst du immer noch später.

Cheers,

Jonas, Co-Founder von Sliplane