The One-Person Framework in der Praxis

 (bramjetten.dev)
35 Punkte von GN⁺ 2025-04-30 | 4 Kommentare | Auf WhatsApp teilen
  • Ein Praxisbericht eines Solo-Entwicklers, der alle Services allein mit Rails entwickelt und gewartet und damit 1 Mio. Euro ARR (wiederkehrender Umsatz) erreicht hat
  • Gestartet wurde zunächst nur mit einem einfachen MVP, das später durch einen kompletten Rewrite und strukturelle Verbesserungen zu einer wartbaren Architektur ausgebaut wurde
  • Der Kern liegt in der konsistenten Philosophie und den Komponenten von Rails sowie der Fähigkeit, mit Turbo Native mobile Apps zu bedienen
  • Eine effiziente Architektur, die den gesamten Traffic und die Nutzung bewältigte und sich dabei mit monatlichen Serverkosten von unter 1.500 Euro betreiben ließ
  • Am Ende wurden Anteile teilweise an einen langfristig orientierten Investor verkauft und 14 Jahre später der zweite Entwickler eingestellt, womit eine neue Phase begann

The One-Person Framework in der Praxis

1 Mio. Euro ARR mit Rails allein erreichen

  • Anfang 2022 überschritt PlanGo die Marke von 1 Mio. Euro Annual Recurring Revenue (ARR) – eine traumhafte Leistung für einen Service mit einer einzigen Rails-Codebasis und nur einem Entwickler
  • Alle Bereiche außerhalb der Technik – Vision, Kundengewinnung, Wachstumsstrategie – wurden von dem Mitgründer und dem Kundensupport-Team übernommen, doch von der Architektur über Deployment und Betrieb bis hin zu Frontend- und Backend-Implementierung wurde alles allein gestemmt
  • DHHs Idee des „One Person Framework“, also einer Struktur, in der ein einzelner Entwickler die gesamte Anwendung betreuen kann, wurde nicht nur theoretisch behauptet, sondern praktisch bewiesen
  • Die strukturelle Philosophie von Rails – von Datenbankdesign über Business-Logik bis zur Frontend-UI innerhalb eines konsistenten Toolsets – ist besonders vorteilhaft für kleine Teams oder Solo-Gründer
  • Dieser Artikel richtet sich an folgende Menschen:
    • Rails-Entwickler: Menschen, die sich fragen, ob man auch heute noch allein ein großes Produkt bauen kann
    • Tech-Gründer: Menschen, die viele Rollen gleichzeitig tragen und sich überlastet fühlen
    • Menschen, denen Handwerkskunst und Technologieentscheidungen wichtig sind

Die Ausgangslage

  • Der Autor stieg 2011 im Alter von 21 Jahren als Entwickler in Rails ein, nachdem er zuvor an einem PHP-(CodeIgniter-)Projekt gearbeitet hatte
  • Es gab keinen großen strategischen Plan; begonnen wurde aus dem einfachen Wunsch heraus, Rails im Trend auszuprobieren
  • Auf Basis der Marketingidee des Mitgründers wurde zur Einführung eine Aktion umgesetzt: Wer sich in der Launch-Woche anmeldete, bekam ein Jahr gratis
    • Erwartet wurden einige Dutzend Anmeldungen, tatsächlich registrierten sich jedoch mehr als 500 Personen in der ersten Woche
    • Weil das Produkt nur auf MVP-Niveau war, folgten sofort Hunderte Feature-Wünsche, Fragen und Support-Anfragen
  • Der Server lief stabil, aber die Kundenanforderungen explodierten, obwohl das Produkt noch nicht fertig war
  • Beide Mitgründer hatten noch einen Hauptberuf, weshalb eine Reaktion in Vollzeit unmöglich war
    • Dadurch entstand die Situation, dass viele frühe Nutzer zwangsläufig enttäuscht wurden
    • Diese Erfahrung machte deutlich, dass Software zu entwickeln und ein Software-Business zu betreiben zwei völlig verschiedene Dinge sind
  • Die Lehre daraus: Funktionen allein reichen nicht; man braucht nachhaltige Kundenbetreuung, Erwartungsmanagement und belastbare Betriebsprozesse

Lernen, während man baut

  • Die Entwicklung begann mit Rails-Tutorials und Stack Overflow, doch eine Anwendung zu bauen, die im Produktivbetrieb reale Kundengeschäfte trägt, ist eine völlig andere Liga
  • Der frühe Rails-Code enthielt die folgenden typischen Anfängerfehler:
    • Controller-Methoden mit über 200 Zeilen
    • Riesige Models mit vermischten Verantwortlichkeiten
    • Ineffiziente SQL-Abfragen
    • Kein Testcode
    • In Git eingecheckte Konfigurationswerte und Secret Keys
  • Features ließen sich zwar umsetzen, doch die gesamte Anwendung stützte sich auf Behelfscode und eine instabile Struktur
  • Benutzer-Authentifizierung, Datei-Uploads, PDF-Erzeugung, Admin-UI, E-Mail-Verarbeitung und weitere Funktionen wurden schnell mithilfe von Gems umgesetzt, doch mit der Zeit verursachte jedes Gem neue Komplexität und neue Probleme
  • Beim Einsatz von .round(2) trat entgegen der Erwartung „banker's rounding“ auf, was zu Fehlern bei Geldbeträgen führte
    • Weil selbst einfache Berechnungen an externe Gems abgegeben wurden, traten Probleme auf, weil das grundlegende Verständnis der Zahlenverarbeitung fehlte
  • Um 2013 herum wuchs mit der Betriebserfahrung zugleich auch die technische Schuld rapide, und neue Features wurden immer schwerer umzusetzen

Kompletter Rewrite

  • Ein vollständiger Rewrite gilt allgemein als riskante und ineffiziente Entscheidung, dennoch fiel 2014 die Entscheidung, auf Basis von Rails 4 komplett von vorn neu aufzubauen
  • Über mehrere Monate hinweg wurden Wartung der bestehenden Anwendung und Entwicklung der neuen Codebasis parallel als fokussierte Arbeit betrieben
  • Die Architektur wurde vereinfacht, die Gem-Abhängigkeiten auf weniger als die Hälfte reduziert und für Kernfunktionen Tests eingeführt
  • Die neue Struktur war kompakter und schneller als die vorherige und wurde vor allem so entworfen, dass sie für einen Teilzeit-Solo-Entwickler wartbar blieb
  • Dieser Rewrite wurde zur technischen Grundlage, auf der ein einzelner Entwickler das Produkt über mehr als zehn Jahre betreiben konnte

Rails ist eine Superkraft

  • PlanGo wurde bis 2025 von nur einem Entwickler betrieben, und der entscheidende Grund dafür war Rails
  • Dank struktureller Eigenschaften von Rails wie Convention over Configuration, Integrationstests, ActiveRecord, ActiveStorage und ActiveJob konnten nicht wesentliche Entscheidungen minimiert und der Fokus auf die eigentliche Wertschöpfung gelegt werden
  • Seit der Einführung von Turbolinks und Hotwire war es möglich, auch ohne komplexes JS-Framework moderne UIs umzusetzen
  • Zu Beginn der Entwicklung 2011 gab es kaum Nachfrage nach mobilen Apps, später wurden iOS- und Android-Apps jedoch zur wichtigsten Schnittstelle von PlanGo
  • Beim Ausprobieren verschiedener Frameworks wie Titanium, RubyMotion und Objective-C zeigte sich das Spannungsfeld zwischen Qualität und Geschwindigkeit
  • Mit der Einführung von Turbo Native stieg die Produktivität sprunghaft, und mit grundlegenden Native-Development-Kenntnissen ließ sich auf Basis der Rails-Codebasis eine hochwertige App umsetzen
  • Dieser Ansatz ist besonders für B2B- oder SaaS-Apps ideal, weil sich native Performance und Nutzererlebnis mit geringen Entwicklungskosten erreichen lassen
  • Das Ergebnis waren mehr als 100.000 App-Downloads pro Jahr und zeitweise sogar eine Platzierung im niederländischen App Store vor Duolingo
  • Alle Apps wurden von einem einzigen Rails-Entwickler entwickelt und gewartet
  • Wichtige Kennzahlen:
    • Ruby-Code: 36.170 Zeilen
    • JavaScript-Code: 13.495 Zeilen
    • Testabdeckung: 40 %
    • Täglich aktive Nutzer: 6.332
    • Requests pro Minute in Spitzenzeiten: 7.000
    • Monatliche Serverkosten: unter 1.500 €
  • Die strukturierte monolithische Architektur beizubehalten, war eine der besten Entscheidungen: einfache Deployments mit Capistrano und leichtes Debugging – ganz ohne die Komplexität von Microservices
  • Für Tech-Gründer ist Rails nicht nur ein Framework, sondern eine Superkraft, die eine Person in die Lage versetzt, die Arbeit eines ganzen Teams zu leisten

Über 1 Mio. Euro hinaus

  • Ende 2022 kam ein unerwarteter Wendepunkt: Ein ausländischer Investor zeigte Interesse an PlanGo und unterbreitete ein Übernahmeangebot
  • Zu diesem Zeitpunkt hatte PlanGo gebootstrapped die Marke von 1 Mio. Euro ARR überschritten und verfügte auch ohne externes Kapital über eine nachhaltige Ertragsstruktur und einen effizienten Betrieb
  • Dieses Angebot gab dem Team Anlass zur Frage: „Was wollen wir künftig eigentlich?“
  • Es wurden verschiedene Möglichkeiten ausgelotet: beim bisherigen Modell bleiben, mit externem Kapital skalieren oder komplett verkaufen
  • Die Verbundenheit mit dem Geschäft war weiterhin groß, zugleich entstand aber die Erkenntnis, dass sich mit mehr Ressourcen und mehr Expertise Chancen leichter umsetzen lassen
  • Auch aus Sicht der Gewinnrealisierung war die Option sinnvoll, einen Teil des über mehr als zehn Jahre aufgebauten Werts zu realisieren und das Geschäft dennoch weiter wachsen zu lassen
  • Schließlich fiel die Entscheidung auf eine Partnerschaft mit einem niederländischen Evergreen-Fonds, dessen Werte und langfristige Ausrichtung gut passten
    • Ein Teil der Anteile wurde verkauft, während Kontrolle und Mehrheitsbeteiligung erhalten blieben
    • Zusätzliche Ressourcen wurden gewonnen, ohne die bestehende Struktur und Kultur zu beschädigen
  • Diese Entscheidung ist Teil einer stabilen Wachstumsstrategie auf Basis eines nachhaltigen und kundenorientierten Geschäfts, nicht eines kurzfristigen Exits oder aggressiver Expansion
  • Auch danach blieb der Rails-basierte Ansatz unverändert, während eine neue Phase begann, in der Chancen aktiver verfolgt werden konnten, die zuvor schwer anzugehen gewesen wären

Erkenntnisse

  • Die folgenden Lehren ergaben sich aus 14 Jahren PlanGo als Solo-Tech-Gründer
  • Embrace Rails conventions
    • Es ist wichtig, nicht gegen die Philosophie und Konventionen von Rails zu arbeiten
    • Der „Rails Way“ ist eine bereits bewährte Methode zur Problemlösung, und je stärker man ihm folgt, desto besser kann man sich auf den eigentlichen Produktwert konzentrieren
  • Less is more
    • Gems oder JS-Bibliotheken ermöglichen eine schnelle Umsetzung von Funktionen, erhöhen aber zugleich Komplexität und Ausfallrisiken
    • Bevor neue Abhängigkeiten hinzugefügt werden, sollte man sich immer fragen: „Brauche ich das wirklich?“
  • Find a community
    • Für Solo-Entwickler ist die Verbindung zu anderen Rails-Entwicklern besonders wichtig
    • So wurde etwa die Community rund um Spina CMS zwar nicht zu Kolleginnen und Kollegen, aber zu einer wertvollen Verbindung für Wissensaustausch und Feedback
  • Technical debt isn't always bad
    • Manchmal ist eine pragmatische Entscheidung für einen schnellen Markteintritt besser als technische Perfektion
    • Entscheidend ist, bewusst zu unterscheiden, wann man technische Schuld eingeht und wann man sie zurückzahlt
  • You can go far alone
    • Mit Rails kann auch ein einzelner Entwickler Produkte in Team-Größe entwerfen, skalieren und deployen
    • Man muss sich nicht von der gängigen Annahme einschränken lassen, dass es dafür zwingend ein Team braucht

Ausblick

  • Der neue Investmentpartner stimmte dem schlanken Betriebsmodell von PlanGo zu, stellte aber genau eine Bedingung: ein zusätzlicher Rails-Entwickler
  • Das Problem war nicht, dass man auf Solo-Entwicklung beharrte, sondern wie schwierig es ist, einen neuen Entwickler in eine über 14 Jahre gewachsene Codebasis einzuarbeiten
  • Die Codebasis war nicht nur die Evolution von PlanGo, sondern auch eine Struktur, in der die persönliche Entwicklung vom Anfänger zum erfahrenen Entwickler vollständig eingeschrieben war, und
    Urteile und Codestile aus verschiedenen Phasen des eigenen früheren Ichs existierten darin nebeneinander
  • Mit der Einstellung des zweiten Rails-Entwicklers, den man auf der Rails World in Kanada kennenlernte, entstanden strukturelle Veränderungen und positive Effekte
    • Das technische Risiko eines Single Point of Failure wurde beseitigt
    • Neue Perspektiven und Ideen kamen hinzu
    • Die Codequalität verbesserte sich durch Pair Programming
    • Die Zusammenarbeit mit einem Entwicklerkollegen, der dieselbe Sprache spricht, brachte zusätzlichen intellektuellen Anreiz
  • Auch künftig ist kein großes Entwicklungsteam geplant
  • Wie bereits bewiesen wurde, kann ein kleines, aber starkes Team mit einem Rails-basierten Ansatz bedeutende Software bauen
  • Gleichzeitig zeigte sich, dass selbst der effizienteste Solo-Entwickler mit guten Teammitgliedern noch weiter wachsen kann
  • Die Reise von PlanGo ist ein Beispiel dafür, dass Rails als One-Person Framework in der Praxis funktioniert, und
    ein Beleg dafür, dass kleine Teams mit den richtigen Werkzeugen ernsthafte Unternehmen nach ihren eigenen Maßstäben aufbauen können
  • Ob man nun als Solo-Entwickler das erste Produkt baut oder als kleines Team über den Tech-Stack nachdenkt: Diese Geschichte soll zeigen, welche Möglichkeiten entstehen, wenn man Rails maximal ausnutzt

Verwandte Beiträge

4 Kommentare

 
xguru 2025-04-30

Ich habe aus diesem Inhalt mit der Audio Overview von NotebookLM einen Podcast erstellt.

https://notebooklm.google.com/notebook/…

Das ist schon ziemlich gut. Ich muss es noch etwas weiter ausarbeiten.
 
dlehals2 2025-04-30

Wow … das ist wirklich unglaublich. Dass es sich so natürlich anfühlt.
 
rococogg 2025-04-30

Wow, die Informationen gehen direkt ins Ohr ...
 
GN⁺ 2025-04-30
Hacker-News-Kommentare

  • Ein Nutzer mit einer Django-ähnlichen Erfahrung betreibt seine eigene App

    • Die größte App ähnelt dem ERP eines mittelgroßen Unternehmens und umfasst verschiedene Berechtigungsstufen
    • Er hat die meisten Funktionen innerhalb eines Monats in Produktion gebracht, eine Aufgabe, für die ein Team normalerweise 2 Jahre brauchen würde
    • Die monatlichen Page Views liegen bei 1–2 Millionen, und zur Reduzierung der Serverlast werden statisches HTML und Cloudflare verwendet
    • Er hält alles so einfach wie möglich, vermeidet REST/Frontend-Frameworks und nutzt HTML-Formulare auf Bootstrap-Basis
    • JavaScript wird nur bei Bedarf verwendet; aktuell kommen AlpineJS/HTMX zum Einsatz

  • Ein Nutzer meint, dass Menschen wichtiger sind als Frameworks

    • Er hat ein auf seinen eigenen Entwicklungsstil zugeschnittenes Framework geschrieben und dadurch Zeit und Kosten gespart
    • Verallgemeinerte Frameworks seien in Teamumgebungen nützlich, im Umfeld eines einzelnen Entwicklers aber nicht so wichtig

  • Ein Nutzer teilt seine Erfahrungen mit Rails und Phoenix

    • Diese seien nützlich beim Bau traditioneller Web-Apps, ähnlich wie die Wahl von Postgres
    • Aktuell nutzt er Clojure und konzentriert sich auf serverseitige Domänenlogik und API-Aufrufe

  • Ein Nutzer berichtet von einem Vortrag darüber, dass Rails 7+ auch Solo-Entwicklern hilft, ambitionierte Apps zu bauen

  • Ein Nutzer teilt die Erfahrung, dass ein neuer Partner zusätzliche Rails-Entwickler einstellen wollte

    • Die Codebasis spiegelt den Wachstumsprozess des Entwicklers wider und enthält Entscheidungen aus sehr unterschiedlichen Erfahrungsstufen
    • Er berichtet auch von einer Codebasis aus einem anderen Unternehmen, die von einem unerfahrenen Entwickler begonnen wurde

  • Ein Nutzer baut seine App mit AdonisJS

    • Nach einem Vergleich von Rails, Adonis und Fiber entschied er sich für Adonis
    • Tutorial-Videos und Dokumentation seien hervorragend; außerdem erwähnt er, dass LLMs bei älteren Versionen verwirrt sein könnten

  • Ein Nutzer findet, dass Rails in vielerlei Hinsicht besser ist als Django

    • Er erwähnt Hotwire, SOLID Cache/Queue, Turbo Native und mehr
    • Bevorzugt aber weiterhin das Python-Ökosystem

  • Es gibt einen Solo-Entwickler, der seine App mit Rails baut

    • Mit Hotwire Native entwickelt er auch eine mobile App
    • Er erwähnt, dass das Rails-Ökosystem erstaunlicherweise alles abdecken kann

  • Ein Nutzer argumentiert, dass man vollständige Rewrites vermeiden sollte

    • Der Rewrite war mehrere Monate konzentrierter Arbeit, während parallel die bestehende App weiter betrieben und eine Ersatz-App gebaut wurde
    • Bei kleinen Apps könnte Refactoring besser sein als ein Rewrite

  • Ein Nutzer hält Frameworks für nicht besonders wichtig

    • Er meint, es reiche aus, etwas Populäres zu wählen, dann bekomme man genug Hilfe
    • Er verwendet Laravel seit 11 Jahren und findet die Business-Seite schwieriger