Wie man mit einem 20-Dollar-Stack mehrere Unternehmen mit 10.000 Dollar Monatsumsatz betreibt

 (stevehanov.ca)
63 Punkte von GN⁺ 17 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Bootstrapping-Strategie, um mit Infrastrukturkosten von unter 20 Dollar pro Monat mehrere SaaS-Unternehmen mit mehr als 10.000 Dollar MRR zu betreiben – unter Nutzung eines einzelnen VPS, der Sprache Go, SQLite und einer lokalen GPU
  • Statt AWS oder komplexer Cloud-Orchestrierung laufen alle Dienste auf einem einzigen VPS für 5 bis 10 Dollar, sodass man sich auf die Verarbeitung von Anfragen statt auf Infrastrukturmanagement konzentrieren kann
  • Als Backend-Sprache wird Go gewählt, um einen extrem einfachen Deployment-Prozess zu erhalten: ohne Abhängigkeitsmanagement zu einer einzelnen Binärdatei kompilieren und anschließend auf dem Server bereitstellen
  • Durch den Betrieb von VLLM auf einer lokalen GPU (RTX 3090) werden die Kosten für AI-Batch-Verarbeitung auf null gesenkt; nur für nutzerseitige Funktionen kommen über OpenRouter Frontier-Modelle zum Einsatz
  • Auch ohne Venture Capital kann man sich durch nahezu null laufende Kosten eine praktisch unbegrenzte Runway sichern und so genug Zeit gewinnen, Product-Market-Fit zu finden

Lean-Strategie für den Serverbetrieb

  • Die übliche Art, 2026 eine Web-App zu starten, ist das Provisionieren eines EKS-Clusters, einer RDS-Instanz und eines NAT Gateway auf AWS; dabei entstehen schnell Kosten von über 300 Dollar im Monat – selbst ohne einen einzigen Nutzer
  • Als Alternative wird ein VPS für 5 bis 10 Dollar pro Monat bei Linode oder DigitalOcean gemietet und alles auf einem einzelnen Server betrieben
  • Selbst 1 GB RAM reichen bei sinnvoller Nutzung aus; wenn etwas Puffer nötig ist, hilft eine Swap-Datei
  • Mit nur einem Server weiß man genau, wo sich die Logs befinden, warum etwas abgestürzt ist und wie man es neu startet
  • Der Grund, statt AWS einen VPS zu wählen, sind vorhersehbare Kosten und eine einfache Architektur

Warum Go gewählt wird

  • Python oder Ruby verbrauchen schon durch das Starten des Interpreters und das Verwalten von gunicorn-Workern die Hälfte des RAM
  • Go liefert bei Web-Workloads deutlich bessere Performance, hat ein strenges Typsystem und ist im Jahr 2026 eine Sprache, über die LLMs sehr leicht schlussfolgern können
  • Der wichtigste Vorteil von Go ist die Einfachheit des Deployment-Prozesses: Die komplette Anwendung wird zu einer einzelnen statisch gelinkten Binärdatei kompiliert, auf dem Laptop gebaut und per scp auf den Server kopiert und dort ausgeführt
  • Es gibt keine pip install-Abhängigkeitshölle und keine virtuellen Umgebungen, und auch ohne aufgeblähte Frameworks lässt sich ein Webserver auf Produktionsniveau bauen
  • Schon mit der Go-Standardbibliothek allein kann man einen Server schreiben, der Zehntausende Anfragen pro Sekunde verarbeitet

Lokale AI nutzen: Batch-Jobs auf null Kosten bringen

  • Wer zu Hause eine Grafikkarte hat, besitzt im Grunde bereits unbegrenzte AI-Credits
  • Beim Aufbau von eh-trade.ca war groß angelegte qualitative Aktienanalyse nötig, bei der Quartalsberichte von Tausenden Unternehmen ausgewertet werden mussten; mit der OpenAI API hätte das mehrere hundert Dollar kosten können
  • Stattdessen lief VLLM auf einer für 900 Dollar über Facebook Marketplace gekauften RTX 3090 (24 GB VRAM), wodurch keine Kosten mehr an AI-Anbieter gezahlt werden mussten
  • Der Upgrade-Pfad für lokale AI:
    • Mit Ollama starten: per Einzeiler (ollama run qwen3:32b) eingerichtet, ideal zum sofortigen Testen verschiedener Modelle und für Prompt-Iterationen
    • Für die Produktion auf VLLM umsteigen: Ollama wird bei gleichzeitigen Anfragen zum Flaschenhals, während VLLM durch PagedAttention drastisch schneller ist. Schickt man 8 bis 16 asynchrone Anfragen gleichzeitig, werden sie im GPU-Speicher gebatcht und fast in derselben Zeit verarbeitet wie eine einzelne Anfrage
    • Transformer Lab: Wenn Vortraining oder Fine-Tuning eines Modells nötig ist, lässt sich das einfach auf lokaler Hardware ausführen
  • Zur Verwaltung davon wurde laconic selbst entwickelt: ein Agenten-Forschungstool, optimiert für ein 8K-Kontextfenster, das wie der virtuelle Speicher-Manager eines Betriebssystems unnötige Teile von Gesprächen „auslagert“, damit nur die Kernfakten im aktiven LLM-Kontext bleiben
  • llmhub: ein Tool, das alle LLMs über die Kombination aus provider/endpoint/apikey abstrahiert und Text- sowie Bild-I/O nahtlos lokal oder in der Cloud verarbeitet

Zugriff auf Frontier-Modelle über OpenRouter

  • Nicht alles lässt sich lokal verarbeiten; für nutzerseitige Chat-Interaktionen mit niedriger Latenz braucht man modernste Reasoning-Modelle wie Claude 3.5 Sonnet oder GPT-4o
  • Statt getrennt Billing-Konten, API-Schlüssel und Rate Limits für Anthropic, Google und OpenAI zu verwalten, wird alles über OpenRouter gebündelt
  • Mit nur einer OpenAI-kompatiblen Integrationslogik erhält man sofortigen Zugriff auf alle wichtigen Frontier-Modelle
  • Unterstützt wird auch nahtloses Fallback-Routing: Fällt die Anthropic API aus, wird automatisch auf ein gleichwertiges OpenAI-Modell umgeschaltet, sodass Nutzer keinen Fehlerbildschirm sehen und keine komplexe Retry-Logik nötig ist

Kosteneffizientes AI-Coding mit GitHub Copilot

  • Während jede Woche neue teure Modelle erscheinen, geben Entwickler monatlich Hunderte Dollar für Cursor-Abos und Anthropic-API-Schlüssel aus
  • Dagegen steigen die monatlichen Kosten selbst bei ganztägiger Nutzung von Claude Opus 4.6 kaum über 60 Dollar
  • Das Geheimnis ist die Nutzung des Preismodells von Microsoft: 2023 wurde ein GitHub-Copilot-Abo abgeschlossen und mit dem normalen VS Code verbunden
  • Der entscheidende Trick bei Copilot: Microsoft berechnet nicht pro Token, sondern pro Anfrage, und eine „Anfrage“ ist einfach eine Eingabe im Chat-Fenster. Selbst wenn der Agent 30 Minuten lang die gesamte Codebasis analysiert und Hunderte Dateien ändert, kostet das nur etwa 0,04 Dollar
  • Die optimale Strategie: einen detaillierten Prompt mit strengen Erfolgskriterien schreiben, dann anweisen, „weiterzumachen, bis alle Fehler behoben sind“, und ausführen lassen

SQLite als Datenbank für alles

  • Beim Start eines neuen Ventures wird immer sqlite3 als Hauptdatenbank verwendet
  • Aus Enterprise-Sicht scheint ein Datenbankserver als separater Prozess nötig zu sein, doch in Wirklichkeit ist eine lokale SQLite-Datei, die über eine C-Schnittstelle oder direkt im Speicher angesprochen wird, um Größenordnungen schneller als ein entfernter Postgres-Server mit TCP-Netzwerk-Hop
  • Ein verbreitetes Missverständnis zur Nebenläufigkeit ist die Annahme, SQLite sperre bei jedem Schreibvorgang die gesamte Datenbank; das wird durch Aktivierung von Write-Ahead Logging (WAL) gelöst
    • Mit PRAGMA journal_mode=WAL; und PRAGMA synchronous=NORMAL; blockieren sich Lese- und Schreibzugriffe nicht gegenseitig
    • Mit einer einzelnen .db-Datei auf einem NVMe-Laufwerk lassen sich Tausende gleichzeitige Nutzer bedienen
  • Um die Implementierung der Benutzerauthentifizierung zu vereinfachen, wurde die eigene Bibliothek smhanov/auth entwickelt: Sie integriert sich direkt in die verwendete Datenbank und unterstützt Registrierung, Sessions, Passwort-Reset sowie Logins über Google/Facebook/X/SAML

Fazit: Startups ohne komplexe Infrastruktur bauen

  • Die Tech-Branche behauptet oft, dass für den Aufbau eines echten Geschäfts komplexe Orchestrierung, hohe monatliche AWS-Kosten und Millionen an Venture Capital nötig seien – das stimmt nicht
  • Kombiniert man einen einzelnen VPS, statisch kompilierte Binärdateien, lokale GPU-Hardware für Batch-AI-Jobs und die rohe Geschwindigkeit von SQLite, lässt sich ein skalierbares Startup zum Preis einiger Tassen Kaffee pro Monat bootstrappen
  • Das gibt einem Projekt unbegrenzte Runway und verschafft Zeit, sich auf die Lösung von Nutzerproblemen zu konzentrieren statt sich über die Burn Rate Sorgen zu machen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 17 일 전
Hacker-News-Kommentare

  • In Unternehmensumgebungen ist die Vorstellung weit verbreitet, man müsse einen externen DB-Server verwenden, aber in der Praxis ist eine lokale SQLite-Datei beim Zugriff über die C-Schnittstelle oder den Speicher viel schneller als ein entfernter Postgres
    SQLite ist natürlich großartig, aber wenn man sich auf localhost per Unix-Domain-Socket mit Postgres verbindet, lässt sich der Netzwerk-Overhead fast vollständig eliminieren
    Es ist nicht wesentlich schwieriger zu benutzen als SQLite, man kann alle Funktionen von Postgres nutzen, und Dinge wie Reporting, Read Replicas oder HA-Setups sind deutlich einfacher
    Postgres auf demselben Server wie die App zu betreiben, ist eine völlig andere Entscheidung als die Übervorsorge, gleich einen Kubernetes-Cluster aufzubauen

    • Selbst auf derselben Maschine ist SQLite deutlich schneller als Postgres über Domain Sockets (100.000-TPS-Beispiel)
      Wenn man eine monolithische App auf einer einzelnen Maschine betreibt, bietet Postgres gegenüber SQLite nicht besonders viele zusätzliche Vorteile
      SQLite lässt sich mit Application functions direkt in der Anwendungssprache erweitern, und dank Litestream sind auch Backups und Replikation deutlich besser geworden
      Allerdings sind die Standardeinstellungen nicht ideal, daher sollte man Lese- und Schreibverbindungen trennen und die Write Queue direkt in der App verwalten
    • Wenn man tatsächlich 100.000-mal SELECT 1 ausführt, braucht Postgres 2,77 Sekunden, SQLite (in-memory) dagegen 0,07 Sekunden — ein erheblicher Unterschied (Benchmark-Link)
    • Ich habe SQLite mit Erweiterungen schon in einem Hochleistungsszenario eingesetzt, in dem Millionen von Dokumenten pro Sekunde verarbeitet wurden
      Mit einem entfernten Server wäre es auch möglich gewesen, aber deutlich komplexer
      Stattdessen haben wir die DB auf S3 gelegt, sodass jede Instanz eine Kopie ziehen und parallel verarbeiten konnte. SQLite ist eine bewährte Alternative, wenn es eher auf Performance als auf Funktionsumfang ankommt
    • Ist die Aussage „man kann alle Funktionen von Postgres nutzen“ nicht genau der YAGNI-(You Ain’t Gonna Need It)-Ansatz, den der TFA kritisiert?
    • Je mehr Funktionen man gar nicht braucht, desto eher sind sie ein Nettoverlust. Die ideale DB bietet nur die Funktionen, die man tatsächlich benötigt

  • Viele glauben, man müsse von Anfang an komplexe Setups mit Serverless, Kubernetes, Multi-Zone-HA und Ähnlichem aufbauen
    Wenn man sagt: „Es läuft auch einfach auf einem günstigen VPS“, kommen sofort Reaktionen wie „Und das Skalieren?“, „Und die Backups?“, „Und die Wartung?“ — dabei werden im Grunde nur Cloud-Marketing-Floskeln wiederholt
    Diese Haltung kommt einer erlernten Hilflosigkeit nahe

    • Als ich als Berater gearbeitet habe, habe ich für Apps mit nicht einmal 200 Nutzern 25 Cloud-Komponenten entworfen. Das war alles das Ergebnis davon, dass „Cloud = muss komplex sein“ eingeübt worden war
    • IT-Einkäufer geben bereitwillig Firmenbudget dafür aus, sich mit den Dingen nicht selbst befassen zu müssen
    • Heute sehe ich dasselbe Phänomen auch bei agentenbasierten Workflows. Die Trainingsdaten sind voller Codebasen für große Teams, wodurch selbst kleine Projekte zu riesigen Strukturen gedrängt werden
      Zum Beispiel werden in eine einfache SPA mit ein paar Eingabeformularen gleich Shadcn, Tailwind, React, Zod und Vite hineingepackt. Der Wartungsaufwand ist enorm
      Solche Setups mögen die „richtige Antwort“ sein, aber nicht unbedingt die situationsgerechte Antwort
    • Die „Cloud-Native-Generation“ hatte dank Gratis-Tarifen nie die Chance zu lernen, was eine grundlegende App tatsächlich braucht
    • Trotzdem halte ich Backups für wichtig

  • Ich nutze Linode oder DigitalOcean und zahle nur 5 bis 10 Dollar im Monat. 1 GB RAM reicht völlig
    Wenn man mehrere Projekte auf einem einzigen dedizierten Server bündelt, lassen sich die Kosten weiter senken
    Ich nutze zum Beispiel einen Server für 40 Euro pro Monat aus der Hetzner Serverbörse und lasse darauf Proxmox laufen (Proxmox-Link)
    Selbst mit 15 VMs landet man bei rund 2,66 Euro pro VM, also einer sehr hohen Kosteneffizienz im Verhältnis zur Größenordnung
    Bei generalüberholter Hardware sind Backups Pflicht, aber die braucht man ohnehin
    Anbieter wie Hetzner, Contabo oder Scaleway sind nach wie vor günstige Optionen

    • Die Hetzner-Preise sind zwar gestiegen, aber OVH bietet zu ähnlichen Preisen neuere Hardware
    • Ich frage mich, warum man VMs nutzt und keine Container
    • Mich würde auch interessieren, wie IPv4 gehandhabt wird. Außerdem ist fraglich, ob es kommerziell erlaubt ist, eine große VM als Hypervisor zu mieten
    • Wäre es nicht effizienter, das einfach in Docker-Containern laufen zu lassen?

  • Ich denke, der größte Kostensenker ist der WAL-Modus von SQLite
    Auch Python oder Node lassen sich genauso gut einsetzen wie Go. Ein VPS von Hetzner mit 4 GB RAM und 10 TB Traffic kostet ungefähr 5 Dollar im Monat
    Wer allerdings einen dedizierten Server nutzt, sollte häufige DB-Backups machen und die Sicherheit selbst verantworten
    Ich setze das so auf, dass ich per Terraform den SSH-Zugriff auf meine IP beschränke, dann Tailscale einrichte und anschließend den öffentlichen SSH-Port schließe

    • Für Backups ist es sicherer, Storage bei einem anderen Anbieter als dem VM-Provider zu verwenden. Man muss auch dann wiederherstellen können, wenn das Konto gesperrt wird
      Ich nutze Backblaze B2, aber mit Restic kann man auch leicht zu anderen Diensten sichern
    • Für SSH-Sicherheit braucht es nicht unbedingt komplizierte Setups. Ein starkes Passwort kann schon ausreichen
    • Ich hatte einmal Postgres mit dem Standardpasswort offen im Netz und wurde innerhalb eines Tages zu einem Bot-Server kompromittiert
      Auch kürzlich haben sich SSH-Versuche innerhalb einer Stunde im Log angesammelt. Inzwischen deaktiviere ich Passwort-Logins und greife nur noch über Tailscale zu
      Ein öffentlich erreichbarer Server ist wirklich gefährlich
    • Dass ein Server in einer Stunde allein über SSH infiziert wird, ist schwer zu glauben. Ohne schwaches Passwort oder offenes VNC dürfte das kaum möglich sein
    • Ich habe beim Umzug einer Django-Seite auf Docker Compose ebenfalls Postgres aufgegeben und auf SQLite WAL umgestellt. Das macht Betrieb und Backups deutlich einfacher

  • Ich halte die Begrenzung auf 1 GB RAM für unnötig. Für 20 Dollar im Monat bekommt man 8 GB RAM, die man für Cache oder DB nutzen kann
    Der Unterschied von 15 Dollar hat auf den Geschäftsbetrieb kaum Einfluss. Sich krampfhaft an einen 5-Dollar-VPS anzupassen, hilft dem Wachstum eines Geschäfts nicht

    • Andererseits sind auch 15 Dollar nicht nichts. Wenn 1 GB reicht, muss man nicht unnötig mehr ausgeben
      Früher lief ein LAMP-Stack auch gut mit 128 MB, und Webseiten sind heute nicht automatisch komplex
    • NVMe-Leselatenzen liegen bei etwa 100 µs, daher kann man auch mit SQLite Hunderte Requests pro Sekunde bedienen
      17 Millionen Requests pro Tag ohne Cache sind machbar; die Infrastruktur schon vorher zu vervierfachen, ist Verschwendung
    • Der eigentliche Grund für das 1-GB-Limit ist das Training, Überengineering zu vermeiden und sich auf den Kundennutzen zu konzentrieren
    • Moderne Systeme sind dank Speicherkomprimierung und NVMe-Swap viel RAM-effizienter
      Das 8-GB-Modell des Macbook Neo ist ein gutes Beispiel dafür
    • Ich finde ebenfalls nicht, dass 15 Dollar einen riesigen Unterschied machen, aber der Kernpunkt ist, die Hosting-Kosten zu minimieren

  • WebSequenceDiagram wirkt wie ein cooles Produkt
    Aber schwieriger als die technische Umsetzung ist es, ein wertvolles Problem zu finden und die Nutzer zu erreichen. Darin steckt der eigentliche Wert

    • Diese Frage stelle ich mir auch. Zwischen Arbeit und Familie reicht der Tag kaum aus. Aber wenn man ein bestimmtes Domänenproblem versteht, wirkt die Lösung oft glasklar
    • Es gibt bereits viele Konkurrenzprodukte. Zum Beispiel Excalidraw

  • Ich habe 2023 GitHub Copilot abonniert, in VS Code eingebunden und nutze es seitdem durchgehend
    Entscheidend ist, dass Microsoft pro Request abrechnet. Selbst wenn mit einer einzigen Anfrage über viele Minuten hinweg der gesamte Code umgebaut wird, kostet das nur etwa 0,04 Dollar
    Deshalb formuliere ich sehr konkrete Prompts und sage dann: „Mach weiter, bis alle Fehler behoben sind“, und gehe einen Kaffee holen. Satya Nadella subventioniert damit praktisch meine Rechenkosten

    • Es gibt allerdings Berichte über gesperrte Konten wegen solcher Ausnutzung pro Anfrage (Reddit-Fall)
    • Der Autor bezeichnet GPT‑4o und Sonnet 3.5 als SOTA; deshalb sollte man die KI-Tipps mit etwas Skepsis lesen
    • (gelöschter Kommentar) sagt, er verstehe nicht, warum er Downvotes bekommen hat

  • Ich habe aus dem Artikel nichts Neues gelernt. Vieles wirkte wie grundlegende Ratschläge, nur von KI verpackt
    Nach dem Titel hatte ich eher erwartet, etwas über Ideenfindung und erfolgreiche Launches zu lesen

    • Bei einem Titel wie „für unter 5 Dollar im Monat“ ist es eigentlich naheliegend, dass grundlegende Tipps kommen. Aber überraschend viele Leute wissen so etwas eben nicht
    • Dann würde ich empfehlen, einen Blog zu starten. Wissen, das für dich banal wirkt, ist für jemand anderen neu
    • Ich würde auch gern 10.000 Dollar verdienen, wenn ich dafür 5.000 Dollar im Monat ausgeben müsste. Das Problem ist, herauszufinden, wie man überhaupt Umsatz erzeugt
    • Der Satz „man braucht modernstes Reasoning von Claude 3.5 Sonnet oder GPT‑4o“ ist ein typischer Fingerabdruck von KI-Texten
    • Aber die vom Autor angesprochene Ressourceninflation existiert wirklich. Ich sehe oft, dass Aufgaben, für die ein einfaches Python-Skript genügt, übertrieben mit AWS und Spark gelöst werden

  • Falls sich noch jemand wie ich gefragt hat: MRR steht für „Monthly Recurring Revenue“

    • Erstaunlich, nach 16 Jahren Mitgliedschaft immer noch nicht zu wissen, was MRR bedeutet
    • Es gibt auch ARR (Annual Recurring Revenue), aber meist ist das einfach künstlich aufgeblasenes MRR mal 12
      Ich habe sogar Leute gesehen, die nach nur zwei Monaten Betrieb schon ARR verkündet haben

  • Cloud-zentriertes Denken erhöht in vielen Fällen unnötig Komplexität und Kosten
    Für die meisten Projekte reicht ein mittelgroßer VPS völlig aus
    Unsere Firma konnte Seiten mit 600.000 Nutzern auf einem 30-Euro-VPS betreiben, ist dann zu AWS gewechselt und zahlt jetzt 800 Euro im Monat. Gewonnen haben wir dadurch nichts
    Wenn es keinen guten Grund gibt, sollte man bei dem einfachen Serveransatz bleiben, der seit Jahrzehnten zuverlässig funktioniert
    Soweit ich weiß, wird auch StackOverflow mit ein paar leistungsstarken Root-Servern betrieben