Warum ein Solo-Entwickler heute schneller liefert als ein 10-Personen-Team

Was gerade in der Tech-Branche passiert

Block hat letzte Woche knapp 4.000 Stellen gestrichen, fast die Hälfte der Belegschaft. Google hat 12.000 Leute entlassen. Meta 11.000.

Alle drei Unternehmen sind profitabel. Umsatz wächst.

Jack Dorsey hat es in seinem Memo an die Mitarbeiter ziemlich direkt formuliert: Kleinere, flachere Teams mit modernen Tools arbeiten besser als große Organisationen.

Ich glaube, er hat recht. Und ich kann das aus meiner eigenen Arbeit bestätigen.

Was ich damit zu tun habe

Seit Anfang 2026 arbeite ich an vier verschiedenen App-Projekten. Gleichzeitig. Alleine.

Und ich liefere schneller als die meisten Teams, die ich kenne.

Das liegt aber nicht daran, dass ich besonders schnell tippen kann. Sondern daran, dass ich etwas anderes mache als die meisten Entwickler: Ich baue nicht einfach Features nach Spezifikation. Wenn jemand mit einer App-Idee zu mir kommt, versuche ich erstmal zu verstehen, was das eigentliche Problem ist. Was brauchen die User wirklich? Wie muss sich die App anfühlen? Was davon ist technisch sinnvoll, was nicht?

Ich übernehme den gesamten Weg von der Idee zum fertigen Produkt. UX, Frontend, Backend, Infrastruktur. Alles aus einer Hand, alles von einem Kopf.

Bei einem klassischen Team läuft das anders. Da erklärt der Gründer seine Idee einem Projektmanager, der gibt sie weiter an den Designer, der gibt sie weiter an den Frontend-Entwickler, der gibt sie weiter an den Backend-Entwickler. Nach vier Übergaben kommt meistens was anderes raus als das, was am Anfang gemeint war.

Vier Projekte, die das zeigen

Hundeo, über 1 Million Downloads

Eine Flutter-App mit Go-Backend. User-System, Push-Notifications, In-App-Purchases, Admin-Dashboard. Ich habe alles gebaut. Mehr zum Projekt.

QUESS, Mental Health mit Bluetooth-Gerät

Kinesiologie-Messungen in Echtzeit, Bluetooth-Integration, Cloud-Sync. Das Backend läuft auf Serverpod. Kein Standardprojekt, aber genau die Art von App, wo es hilft, wenn eine Person den gesamten Stack versteht.

Bori Bau, Test-App nach zwei Wochen

Dokumentations-App für Tiefbau. Aufträge verwalten, Fotos hochladen, Berichte erstellen. Von der Idee zur funktionierenden Test-App in zwei Wochen Entwicklungszeit.

DragonBoat Pro, eigenes Produkt

Sitzverteilung für Drachenboot-Teams. Berechnet auf Basis von Gewicht, Erfahrung und Bootsbalance die optimale Crew. Drachenboot ist meine Leidenschaft, ich bin selbst Trainer und baue die App, die ich mir als Coach immer gewünscht habe.

Vier Apps, komplett unterschiedliche Branchen und Anforderungen. Alles parallel.

Warum parallel funktioniert

In jedem Projekt gibt es Leerlauf. Der Kunde braucht Zeit für Feedback. Apple reviewt das Update. Hardware-Lieferung dauert drei Tage länger.

Wenn ich in einem Team arbeiten würde, hieße das: Meeting einberufen, Statusupdate geben, Tickets umplanen.

Stattdessen wechsle ich einfach zum nächsten Projekt und mache dort weiter, wo ich aufgehört habe. Kein Overhead, keine Wartezeit.

Das Problem mit großen Teams

Es gibt ein Konzept in der Softwareentwicklung, das sich Brooks' Law nennt. Die Kurzfassung: Mehr Leute an einem Softwareprojekt machen es nicht schneller. Ab einem gewissen Punkt machen sie es langsamer.

Fred Brooks hat das schon 1975 beschrieben. Der Grund ist simpel: Je mehr Leute am Code arbeiten, desto mehr Zeit geht für Kommunikation drauf. Dailys, Sprint Planning, Code Reviews, Architecture Meetings, Cross-Team-Abstimmung. 10 Entwickler produzieren nicht 10x so viel Output. Eher 3x, wenn es gut läuft.

Bei mir fällt das alles weg. Ich hab keine Meetings mit mir selbst. Eine Idee geht direkt in die Umsetzung.

Warum "nur ein Entwickler" das falsche Bild ist

Wenn Leute hören, dass eine einzelne Person ihre App baut, denken viele erstmal: Okay, das ist halt die günstige Variante. Weniger professionell, aber billiger.

Das stimmt so nicht mehr.

Die Tools sind heute andere. AI-gestützte Entwicklung, Frameworks wie Flutter, Cloud-Infrastruktur, die man in Minuten aufsetzen kann. Code schreiben ist billig geworden. Wirklich billig. Wie das konkret aussieht, schreibe ich in Wenn die KI deine Flutter-App schreibt.

Ich kann Kundenfeedback direkt nehmen und in funktionierenden Code umsetzen, oft am selben Tag. Neuen Code zu produzieren ist nicht mehr das Problem. Was danach kommt schon: Testen. Bugs finden. Bugs fixen. Sicherstellen, dass das Neue nichts Altes kaputt macht. Jede Änderung muss geprüft werden. Testing ist der neue Engpass.

In einem großen Team wird das schnell zum Chaos. Mehr Pull Requests, mehr Merge-Konflikte, mehr Abstimmung darüber, wer was wann testen soll. Bei mir läuft alles durch einen Kopf. Ich weiß, was ich geändert habe, ich weiß, was davon betroffen ist, und ich kann gezielt testen statt alles blind durchzuprüfen.

Der aufwändige Teil ist heute nicht mehr der Code. Es ist: verstehen, was gebaut werden soll, und schnell reagieren, wenn sich was ändert. Das kann ein einzelner Mensch mit Überblick über das gesamte Projekt oft besser als ein Team, das alles in Teilaufgaben zerlegt hat.

Was das konkret für dich heißt

Falls du gerade überlegst, eine App entwickeln zu lassen: Die Spielregeln haben sich geändert.

Vor ein paar Jahren war ein Team von 5 bis 10 Leuten die "sichere" Wahl. Mehr Leute hieß mehr Absicherung. Zumindest war das die Theorie.

Heute funktioniert das anders. Ein einzelner erfahrener Entwickler, der das Problem wirklich versteht, kann schneller und oft auch besser liefern. Weil es keinen Informationsverlust gibt. Weil Änderungen sofort umgesetzt werden können. Weil du mit einer Person redest und nicht mit einer Kette von Zwischenhändlern.

Du zahlst für das Ergebnis, nicht für die Organisation drumherum. Mehr dazu, was App-Entwicklung tatsächlich kostet, findest du hier.

Wo die Chance liegt

Die meisten Agenturen arbeiten noch nach dem alten Modell. Große Teams, lange Timelines, Budgets mit vielen Nullen. Während die noch ihr Angebot für ein 6-Monats-Projekt mit acht Entwicklern schreiben, hab ich die erste funktionsfähige Version schon beim Kunden.

Nicht weil ich besser bin als acht Leute zusammen. Sondern weil zwischen der Idee und der fertigen App niemand sitzt, der sich mit jemand anderem abstimmen muss.

Wer sich erstmal auf das Wesentliche konzentrieren will, statt monatelang zu planen, findet in meinem Artikel über MVPs mehr dazu.

Fazit

Große Teams waren lange der Standard. Mehr Leute hieß mehr Kompetenz. Das hat sich geändert.

Gerade jetzt, Anfang 2026, merke ich das besonders deutlich. Vier Apps parallel, ein Ansprechpartner, null Overhead. Mit den Tools, die es heute gibt, ist das realistisch. Und meine Kunden bekommen ihre App schneller, als sie es von Agenturen gewohnt sind. Wie ich KI-Agenten dabei im Zaum halte, steht in Skills, Hooks und Quality Gates.

Ob das für jedes Projekt die richtige Lösung ist? Wahrscheinlich nicht. Aber für die meisten App-Projekte, die bei mir landen, schon.

Häufig gestellte Fragen (FAQ)

Dieser Artikel wurde inspiriert von der aktuellen Diskussion um Blocks Personalabbau.