Ich baue neben meinem Job Apps. Und ja, das ist so verrückt wie es klingt.
Tagsüber digitale Transformation bei einem DAX-Konzern. Abends und am Wochenende eigene Apps entwickeln. Kein Team, kein Budget, kein Investor. Nur eine Idee, ein Laptop und die Überzeugung, dass bestimmte Probleme besser gelöst werden können. Das ist meine Realität seit über einem Jahr — und ich möchte ehrlich erzählen, was dabei passiert ist. Nicht die polierte LinkedIn-Version. Die echte.
Die Ideen: Woher sie kamen
Jede gute App löst ein Problem, das du selbst hast. Das ist keine Binsenweisheit, das ist die einzige Regel, die wirklich funktioniert.
Vera entstand aus purer Frustration. Ich bin ein Mensch, der gerne Sprachnachrichten verschickt — aber WhatsApp macht das Erlebnis furchtbar. Du bekommst eine dreieinhalbminütige Nachricht, kannst nicht vorspulen, weißt nicht worum es geht, und wenn du gerade in einem Meeting sitzt, hörst du sie erst drei Stunden später. Bis dahin hast du vergessen, dass sie existiert. Meine Idee: Async Voice Messaging, bei dem du sprichst wann du willst und zuhörst wann du kannst. Private Räume statt öffentlicher Feeds. Ende-zu-Ende-Verschlüsselung, weil das 2026 Standard sein sollte und nicht Luxus. Vera ist mittlerweile in der Beta — iOS und Android, “Coming Soon” im App Store.
OutAndAbout kam aus einer anderen Frustration. Freitagabend, Stuttgart, du willst raus — aber wohin? Google zeigt dir die immer gleichen fünf Bars. Instagram zeigt dir Events aus Berlin. Dein Freundeskreis hat keine Ahnung. Lokale Events sind absurd schwer zu finden, obwohl wir alle ein Supercomputer-Telefon in der Tasche haben. OutAndAbout soll genau das lösen: Was passiert heute, morgen, dieses Wochenende — in deiner Nähe. Kuratiert statt algorithmisch. Kein Doomscrolling, keine Filterbubble. OutAndAbout ist aktuell noch in der Konzeptphase, aber die Idee brennt.
Beide Ideen haben eines gemeinsam: Sie kamen nicht aus einer Marktanalyse. Sie kamen aus meinem Alltag. Und das ist, glaube ich, der einzige Weg, wie ein Solo-Entwickler ein Produkt bauen kann, das nicht nach drei Monaten in der Schublade landet.
Der Techstack: Flutter + Firebase — und warum
Die Techstack-Entscheidung war eine der ersten, die ich treffen musste — und eine der wenigen, die ich bis heute nicht bereue.
Flutter war für mich keine Frage. Als Solo-Entwickler kann ich es mir schlicht nicht leisten, zwei native Apps parallel zu bauen. Eine Codebase für iOS und Android, mit nativer Performance und einem UI-Framework, das tatsächlich Spaß macht? Das ist der Deal. Dart als Sprache ist anfangs gewöhnungsbedürftig, aber nach ein paar Wochen merkst du, wie durchdacht das Ganze ist. Hot Reload alleine spart mir jeden Tag eine halbe Stunde.
Firebase als Backend war die logische Ergänzung. Authentication, Firestore, Cloud Functions, Push Notifications — alles aus einer Hand, ohne eigene Server zu betreiben. Für einen Indie Developer, der abends nach der Arbeit noch produktiv sein will, ist das Gold wert. Kein DevOps, kein Kubernetes, kein Infrastruktur-Kopfschmerz. Einfach bauen.
Natürlich gibt es Trade-offs. Firebase kann bei wachsender Nutzerbasis teuer werden. Vendor Lock-in ist real. Und wenn du sehr spezifische Backend-Logik brauchst, stößt du an Grenzen. Aber für den Weg vom Prototyp zum ersten echten Produkt? Perfekt. Die Optimierung kommt später — wenn du das Luxusproblem hast, dass tatsächlich Menschen deine App nutzen.
Dazu kommt: KI-gestütztes Coding hat meinen Workflow komplett verändert. Mit Tools wie Cursor oder Claude schreibe ich Features in einem Bruchteil der Zeit. Nicht blind — ich verstehe den Code, den die KI generiert. Aber der Hebel ist enorm. Gerade als Solo-Maker, der seine Stunden zählen muss.
Von der Idee zum Prototyp: Was du unterschätzt
Hier wird es ehrlich. Denn die Lücke zwischen “Ich habe eine geile Idee” und “Ich habe ein funktionierendes Produkt” ist ein Abgrund, über den niemand spricht.
Scope Creep ist der stille Killer jedes Side-Projects. Du fängst an mit “eine einfache Voice-Messaging-App” und drei Wochen später sitzt du an einem Emoji-Reaktionssystem mit Custom-Animationen, weil du das auf Dribbble gesehen hast und es “cool wäre”. Ich spreche aus Erfahrung. Bei Vera habe ich mindestens zwei Monate verloren, weil ich Features gebaut habe, die kein Mensch zum Launch braucht.
Perfektionismus ist Scope Creeps hässlicher Bruder. “Noch diese eine Animation glätten.” “Die Onboarding-Screens sind noch nicht perfekt.” “Das Icon gefällt mir nicht.” Klingt harmlos. Summiert sich zu Wochen. Das MVP — Minimum Viable Product — heißt nicht “das Minimum, das ich als Entwickler akzeptabel finde”. Es heißt: Was ist das Minimum, mit dem ein echter Nutzer testen kann, ob die Idee funktioniert?
Und dann ist da die Sache mit der Energie. Du hast einen Vollzeitjob. Du hast ein Leben. Du hast Abende, an denen du einfach keinen Code sehen willst. Das ist normal und das ist okay. Aber es bedeutet auch: Dein Side-Project konkurriert nicht mit einem VC-finanzierten Startup, das fünf Entwickler Vollzeit dran hat. Es konkurriert mit deinem Sofa und Netflix. Und manchmal gewinnt das Sofa. Musst du akzeptieren.
Was mir geholfen hat: Feste Zeitblöcke. Nicht jeden Tag, aber drei bis vier Abende pro Woche, jeweils zwei Stunden. Keine Verhandlung. Kein “ich mache morgen mehr”. Konsistenz schlägt Intensität. Immer.
Indie vs. VC: Bewusst unabhängig
2W Digital ist mein Indie-Studio. Indie heißt: Kein Investor, kein Board, kein Druck von außen. Das ist eine bewusste Entscheidung — kein Notbehelf, weil niemand investieren wollte.
Der Indie-Maker-Ansatz hat in den letzten Jahren massiv an Traktion gewonnen. Leute wie Pieter Levels mit Nomad List und PhotoAI, oder Marc Lou mit ShipFast, zeigen, dass ein einzelner Mensch Produkte bauen kann, die Millionen generieren. Ohne Team. Ohne Büro. Ohne Series A. Die Tools sind da: Flutter für Cross-Platform, Firebase für Backend, KI für Produktivität, Beehiiv oder Substack für Newsletter, Social Media für Distribution. Der gesamte Stack eines Ein-Personen-Unternehmens kostet weniger als ein Mittagessen pro Tag.
Aber lass mich ehrlich sein: Es gibt echte Trade-offs. Ohne VC bist du langsamer. Punkt. Du kannst nicht einfach drei Entwickler einstellen, wenn ein Feature komplex wird. Du kannst kein Marketing-Budget für User Acquisition verbrennen. Du kannst nicht sechs Monate Runway kaufen, um dich Vollzeit auf die App zu konzentrieren.
Dafür bekommst du etwas anderes: Freiheit. Du entscheidest, was du baust. Du entscheidest, wann du launcht. Du musst keinem Investor erklären, warum du Feature X noch nicht fertig hast. Du musst keine Metriken optimieren, die du selbst für sinnlos hältst. Und wenn die App floppt? Dann hast du etwas gelernt, aber niemandem Geld verbrannt.
Meine Philosophie bei 2W Digital ist simpel: Nutzen statt Hype. Ich baue Dinge, die ich selbst nutzen will. Kein Bullshit, nur Signal. Wenn das für andere auch funktioniert — großartig. Wenn nicht, habe ich trotzdem etwas Sinnvolles für mich selbst gebaut. Das klingt vielleicht nicht nach “ambitionierter Startup-Pitch”. Ist es auch nicht. Ist mir auch egal.
Was ich beim nächsten Mal anders machen würde
Hier die ehrlichen Lessons Learned — Dinge, die ich gerne vor 18 Monaten gewusst hätte:
Das MVP noch kleiner schneiden. Ernsthaft. Was ich als “minimal” betrachtet habe, war immer noch drei Mal zu groß. Beim nächsten Projekt würde ich mich fragen: Was ist die eine Kernfunktion? Genau die bauen. Sonst nichts. Alles andere kommt nach dem Launch.
Früher launchen, auch wenn es wehtut. Der Code ist nicht perfekt? Egal. Das Design hat Ecken und Kanten? Egal. Echtes Nutzerfeedback ist mehr wert als hundert Stunden Polieren im stillen Kämmerlein. Ich habe mit Vera zu lange gewartet. Das hole ich auf, aber es hat mich Zeit gekostet.
Marketing ab Tag eins mitdenken. Das ist der klassische Entwickler-Fehler: Du baust ein großartiges Produkt und denkst, die Leute kommen von allein. Spoiler: Tun sie nicht. Ich hätte von Anfang an einen Newsletter, Social-Media-Präsenz und eine Waitlist aufbauen sollen. Nicht erst wenn die App “fertig” ist. Fertig ist sie eh nie.
Mehr in der Öffentlichkeit bauen. “Building in Public” ist kein Marketing-Gimmick — es ist Accountability. Wenn du regelmäßig teilst, woran du arbeitest, bekommst du Feedback, Motivation und eine Community. Ich habe das zu spät angefangen und es bereut.
Gesundheit nicht opfern. Klingt nach Kalenderspruch, ist aber ernst gemeint. Es gab Phasen, in denen ich bis zwei Uhr nachts an Features gebaut habe und am nächsten Tag im Meeting saß wie ein Zombie. Das ist nicht nachhaltig. Und nicht-nachhaltig heißt: Du hörst irgendwann auf. Das Side-Project stirbt nicht an fehlenden Features — es stirbt daran, dass du ausbrennst.
Deine Gedanken dazu:
Hast du selbst ein Side-Project, das du neben dem Hauptjob vorantreibst — und wie gehst du mit der begrenzten Zeit um?
Was hat dich bisher davon abgehalten, eine eigene App oder ein eigenes Produkt zu launchen — und ist der Grund wirklich so groß, wie er sich anfühlt?
Indie und unabhängig bleiben oder doch Investoren reinholen — wo ziehst du die Grenze?
Welches Problem in deinem Alltag nervt dich so sehr, dass du manchmal denkst: Dafür müsste es doch eine App geben?
Building in Public: Teilst du deinen Fortschritt öffentlich — oder baust du lieber still, bis alles “fertig” ist?