ich weiß, du hast auf X gesehen, wie alle mit ihren Agents Mobile Apps bauen.
buchstäblich jeden Tag postet jemand: „in 24h im iOS App Store gelauncht“ und zwei Wochen später: „ich hab 4k $ MRR geknackt“ – und die Antworten sind immer dieselben:
„womit hast du das gebaut?“ „wie hast du user bekommen?“ „drop the sauce“
wenn man genug davon gesehen hat, fängt man irgendwann an, sich zu fragen:
„sollte ich auch mobile apps bauen?“
kurze antwort: VERDAMMT JA.
besonders, wenn du die letzten jahre damit verbracht hast, saas zu bauen.
und ganz besonders, wenn du dir eingeredet hast, dass consumer apps nichts für dich sind, weil du ein „b2b-mensch“ bist.
denn die chance ist groß, dass du schon seit jahren an endverbraucher verkaufst. du hast ihnen nur zufällig ein saas-dashboard vor die nase gesetzt.
hier erkläre ich dir, warum diese unterscheidung wichtig ist – und wie ich so schnell wie möglich von null zu einer veröffentlichungsreifen mobilen app kommen würde.
vielleicht machst du schon b2c
es gibt diesen standard-startup-ratschlag, der überall wiederholt wird:
- verkaufe an unternehmen
- unternehmen haben geld
- b2b-kunden bleiben länger
- konsumenten wollen nicht zahlen
klingt logisch.
bis dein „b2b-saas“ ein analytics-tool für 19 $/monat ist, das du an solo-founder verkaufst.
du bist b2c nicht entkommen.
du hast dir nur eine der härtesten zielgruppen überhaupt ausgesucht.
indie hacker und kleine founder sind extrem preissensibel. sie verstehen, wie software funktioniert, sie vergleichen alles und verbringen locker drei stunden damit, eine open-source-alternative zu suchen, nur um dir keine 20 $/monat zahlen zu müssen.
und die hälfte von ihnen denkt sich:
„das könnte ich wahrscheinlich selbst bauen.“
nur weil du ein stripe-abo über etwas legst, wird es nicht magisch zu b2b.
die viel sinnvollere unterscheidung ist, warum jemand kauft.
ein unternehmen kauft software meistens aus einem wirtschaftlichen grund. es spart den mitarbeitern zeit, senkt kosten, steigert umsatz, ersetzt ein anderes tool oder macht einen prozess einfacher.
konsumenten kaufen aus völlig anderen gründen.
sie wollen besser schlafen.
besser aussehen.
mehr geld sparen.
keine zeit mehr verschwenden.
stärker werden.
sich besser ernähren.
sich organisierter fühlen.
etwas lernen.
mit etwas aufhören.
weniger ängstlich sein.
selbstbewusster werden.
oder einfach das gefühl haben, voranzukommen.
und diese probleme sind riesig, weil im grunde jeder sie hat.
außerdem musst du keine einkaufsabteilung überzeugen, dich in keinen 14-tool-stack integrieren und in keinem sales-call den roi erklären.
du musst nur erreichen, dass eine person dein produkt sieht und denkt:
„moment, das will ich haben.“
das ist ein völlig anderes spielfeld.
und gerade jetzt sind mobile apps einer der einfachsten wege, darauf zu spielen.
warum mobile plötzlich wieder spannend ist
einige dinge passieren genau zur selben zeit.
1. ki hat einen großen teil der technischen hürden zerstört
früher hieß eine ordentliche mobile app zu bauen: swift oder kotlin lernen, ein komplett neues ökosystem verstehen, gegen xcode kämpfen, app-architektur durchdenken – und wahrscheinlich monate investieren, bevor du etwas hattest, das du leuten zeigen konntest.
das ändert sich extrem schnell.
eine fokussierte consumer app kann heute in einem tag von der idee in deinem kopf zu etwas nutzbarem werden.
der flaschenhals ist immer seltener:
„kann ich das bauen?“
sondern:
„sollte ich das bauen?“
und das ist ein viel interessanteres problem.
2. consumer-distribution ist überall
tiktok, reels und shorts können ein völlig unbekanntes produkt millionen menschen zeigen – ohne dass das unternehmen vorher eine audience hatte.
du brauchst nicht zwingend seo.
du brauchst nicht zwingend paid ads.
du brauchst nicht zwingend 50.000 twitter-follower.
ein einziges gutes content-stück kann dir die ersten paar hundert oder tausend user bringen, die du brauchst, um herauszufinden, ob da wirklich etwas dran ist.
3. mobile passt perfekt zu dieser distribution
video sehen.
problem verstehen.
app laden.
produkt testen.
dieser gesamte weg kann in wenigen minuten passieren – auf demselben gerät.
es gibt fast keinen kontextwechsel.
4. du kannst ideen absurd schnell testen
das ist vielleicht die größte veränderung.
wenn ein mvp drei monate dauert, fühlt sich die wahl der idee unglaublich wichtig an.
wenn ein mvp ein bis zwei tage dauert, ändert sich die komplette rechnung.
du musst nicht die eine idee finden.
du musst etwas finden, das interessant genug zum testen ist, die kleinste version bauen, die das kernverhalten beweist, es leuten zeigen und schauen, was passiert.
wenn es niemanden interessiert, hast du etwas gelernt.
wenn leute es einmal nutzen, aber nie wiederkommen, hast du etwas anderes gelernt.
wenn 100 leute es laden und 25 es eine woche später noch öffnen, wird es interessant.
also, so würde ich genau vorgehen.
ERSTER SCHRITT
1) finde nachfrage, bevor du eine idee suchst
öffne keine leere notion-seite und brainstorme keine „startup-ideen“.
du wirst wahrscheinlich lösungen für probleme finden, die hauptsächlich in deinem eigenen kopf existieren.
beobachte stattdessen erstmal menschen.
bei consumer-produkten ist tiktok dafür einer der besten orte.
lad es dir runter.
nimm dir bewusst 5–10 min/tag, um nach mustern zu suchen.
nicht nach zufälligen viralen videos. nach menschlichem verhalten.
halte ausschau nach:
- dingen, über die sich leute ständig beschweren
- gewohnheiten, die sie loswerden wollen
- dingen, bei denen sie unsicher sind
- dingen, mit denen sie angeben
- dingen, die sie obsessiv tracken
- neuen ästhetiken und identitäten
- challenges, die plötzlich alle machen
- dingen, in denen sie gerne besser wären
- routinen, die leute ständig teilen
- dingen, bei denen sie immer wieder um hilfe bitten
- verhaltensweisen, die schon jetzt nervige workarounds erfordern
im grunde suchst du nach menschlichen problemen, die sich unter trends verstecken.
zum beispiel:
es gibt einen trend namens „underconsumption core.“
an der oberfläche geht es darum, dass leute weniger dinge kaufen.
die offensichtliche founder-reflexreaktion wäre:
„lass uns eine underconsumption-app bauen.“
tu das nicht.
frag dich stattdessen, warum sich millionen menschen damit identifizieren.
vielleicht sind die echten probleme:
„ich kaufe impulsiv, wenn ich gestresst bin.“
„ich kaufe ständig sachen, die ich nicht brauche.“
„geld sparen fühlt sich langweilig an.“
„ich habe keine ahnung, wo mein geld jeden monat hinverschwindet.“
„ich möchte dafür belohnt werden, etwas nicht zu kaufen.“
das ist viel interessanter.
jetzt kannst du anfangen, echte produkt-loops zu entwickeln.
vielleicht fügst du jedes mal, wenn du widerstehst etwas zu kaufen, es der app hinzu und dein „gespartes geld“-zähler steigt.
vielleicht fotografierst du etwas, das du gleich kaufen würdest, und die app lässt dich 24 stunden warten.
vielleicht treten freunde gegeneinander an, wer diesen monat die meisten unnötigen käufe vermieden hat.
der trend hat dir das signal gegeben.
das zugrundeliegende verhalten gibt dir das produkt.
die 3 consumer-app-formate, auf die ich immer wieder zurückkomme
du musst auch keine völlig neue kategorie erfinden.
die meisten interessanten consumer apps passen in ein paar grundlegende strukturen.
tracker
mach unsichtbares verhalten zu zahlen.
ausgaben. screen time. schlaf. gewohnheiten. stimmung. essen. fokus. workouts. nüchternheit. lesen. lernen.
menschen lieben es, sich quantifiziert zu sehen, weil etwas abstraktes plötzlich zu sichtbarem fortschritt wird.
„ich war in letzter zeit fokussierter“ ist vage.
„meine durchschnittliche fokuszeit ist von 41 auf 76 minuten gestiegen“ fühlt sich echt an.
coach
hilf jemandem, eine leicht veränderte version seiner selbst zu werden.
tägliche missionen. challenges. pläne. erinnerungen. personalisierte empfehlungen. feedback.
menschen brauchen oft kein weiteres kompliziertes tool mit 40 buttons.
sie brauchen etwas, das ihr ziel versteht und ihnen sagt:
„mach als nächstes das hier.“
das produkt wird wertvoll, weil es entscheidungen abnimmt.
simple utility
nimm eine nervige sache und mach sie angenehm.
timer. listen. tagebücher. notizen. widgets. planer. rechner. scanner.
die funktionalität kann lächerlich simpel sein, solange sich das erlebnis gut genug anfühlt.
ein produkt braucht keine 25 features, um einen platz auf dem homescreen von jemandem zu verdienen.
manchmal ist ein einziges feature, das täglich genutzt wird, viel stärker.
klau ideen aus den kommentaren
noch ein trick:
wenn du einen trend findest, suche in den kommentaren nach wörtern wie „app.“
leute schreiben buchstäblich:
„jemand muss dafür eine app machen“
oder:
„gibt es eine app, die das kann?“
oder:
„ich wünschte, etwas würde das automatisch tracken.“
das ist quasi kostenlose marktforschung.
und es ist viel nützlicher, als leute zu fragen:
„würdet ihr eine app nutzen, die x macht?“
denn sie formulieren das problem bereits selbst, ohne dass du ihnen die idee in den kopf setzt.
2) definiere den loop, bevor du irgendetwas baust
bevor du code anfasst, beantworte eine einfache frage:
was tut jemand in dieser app immer wieder?
nicht: welche features hat sie.
sondern: was ist der loop?
bei einer ausgaben-app könnte das sein:
fast etwas kaufen → eintragen → kauf widerstehen → gespartes geld sehen → fortschritt fühlen → wiederholen
bei einer fitness-app:
app öffnen → heutiges workout erhalten → abschließen → fortschritt sehen → morgen wiederkommen
bei einer fokus-app:
aufgabe wählen → timer starten → session beenden → streak aufbauen → wiederholen
wenn du den kern-loop nicht in einem satz erklären kannst, ist die app wahrscheinlich noch zu kompliziert.
dann stell dir vier weitere fragen:
warum lädt jemand sie herunter?
es sollte ein sehr offensichtliches versprechen geben.
warum versteht jemand sie in 10 sekunden?
der wert sollte kein tutorial erfordern.
was bringt ihnen den ersten erfolg?
bring sie so schnell wie möglich dorthin.
warum öffnen sie sie morgen wieder?
das ist die frage, die founder oft vergessen.
downloads sind nett.
retention ist das produkt.
du brauchst noch keine perfekten antworten. du brauchst nur genug klarheit, damit du nicht eine ki dein gesamtes business erfinden lässt, während sie den code schreibt.
3) übernimm die muster, nicht die pixel
sobald du eine idee und einen grundlegenden loop hast, designe nicht alles von null.
du bist wahrscheinlich kein product designer.
ich auch nicht.
suche stattdessen 5–10 erfolgreiche apps, die dasselbe problem oder dasselbe nutzerverhalten bedienen.
sie müssen nicht mal direkte konkurrenten sein.
wenn du eine spar-app baust, hat vielleicht eine app ein unglaubliches onboarding, eine andere ein tolles streak-system, eine dritte einen befriedigenden fortschritts-screen und eine vierte eine paywall, die dir gefällt.
lade sie herunter.
nutze sie wirklich.
mach dann screenshots von allem:
- erster start
- signup
- onboarding
- homescreen
- navigation
- kernaktion
- empty states
- fortschritts-screens
- streaks
- benachrichtigungen
- upgrade-prompt
- paywall
- einstellungen
das nützliche sind nicht die farben oder die abgerundeten ecken.
es sind die entscheidungen dahinter.
wo stellen sie fragen?
wie viele onboarding-screens gibt es?
wann zeigen sie das eigentliche produkt?
wann fragen sie nach benachrichtigungsrechten?
wann fragen sie nach geld?
wie schnell bekommst du deinen ersten erfolg?
welche informationen sind dauerhaft sichtbar?
was wird versteckt?
was bringt dich dazu, morgen wiederzukommen?
diese unternehmen haben bereits tausende winzige entscheidungen getestet, über die du sonst nur raten müsstest.
also erfinde nicht jede interaktion neu.
schau dir an, was funktioniert, versteh warum, kombiniere die besten muster und gib dem ganzen deine eigene note.
für jüngere consumer-zielgruppen mag ich generell:
- eine offensichtliche aktion pro screen
- riesige typografie
- sehr wenig text
- sichtbaren fortschritt
- streaks
- meilensteine
- befriedigende zahlen
- frühe personalisierung
- sehr offensichtliches feedback, wenn etwas abgeschlossen ist
im grunde:
mach fortschritt unübersehbar.
wenn jemand etwas abschließt, feiere es.
wenn er die app sieben tage genutzt hat, zeig es ihm.
wenn er sich um 18 % verbessert hat, zeig es ihm.
wenn er 143 $ gespart hat, mach diese zahl unignorierbar.
der nutzer sollte ständig verstehen:
„das funktioniert.“
4) mach aus den referenzen eine echte app
hier wird das bauen absurd einfach.
ich habe die meisten tools ausprobiert, mit denen leute heute software per ki bauen.
aber wenn ich schnell von einer idee zu einer echten mobilen app kommen will, nutze ich shipper.
zu diesem zeitpunkt solltest du schon haben:
- deine app-idee
- deinen kern-nutzer
- das ergebnis, das du versprichst
- deinen haupt-produkt-loop
- screenshots von apps, die ähnliche probleme gut lösen
nimm all das und gib es zuerst chatgpt, claude oder grok.
sag nicht:
„bau mir eine budgeting-app.“
damit gibst du dem modell fast nichts zum arbeiten.
gib ihm stattdessen einen richtigen job:
„ich baue eine mobile app, die {user} hilft, {outcome} zu erreichen. analysiere die angehängten referenzen und brich die ux-muster, visuelle hierarchie, onboarding, navigation und interaktionen herunter, die sie nutzen. passe diese muster an mein produkt an. definiere jeden mvp-screen, was auf jedem screen passiert, den kompletten onboarding-weg, die hauptnavigation, den kern-user-loop und einen mechanismus, der usern einen grund gibt, regelmäßig zurückzukehren. entferne alles, was für die erste version nicht nötig ist. verwandle am ende alles in einen detaillierten build-prompt.“
jetzt hast du etwas, das einem produkt-spec viel näher kommt als einem zufälligen prompt.
lies es.
streich den quatsch.
füge hinzu, was es übersehen hat.
nimm dann dieses ergebnis, häng deine screenshots an und pack alles in shipper.
sag ihm genau, was du willst.
die screens.
die interaktionen.
den flow.
die logik.
die winzigen details.
und sprich dann weiter mit ihm, als säße ein entwickler neben dir:
„mach diesen screen simpler.“
„verschieb die paywall, nachdem der nutzer sein erstes ergebnis hat.“
„füg hier einen 7-tage-streak ein.“
„dieses onboarding fühlt sich zu lang an. halbier es.“
„speichere diesen zustand, wenn der nutzer die app schließt.“
„lass diese interaktion nativer für ios wirken.“
„es gibt zu viele optionen auf diesem screen. mach eine aktion dominant.“
genau hier verstehen leute ki-builder falsch.
du musst kein swift können.
du musst nicht jede komponente manuell erstellen.
du musst keine riesige dev-umgebung aufsetzen, nur um herauszufinden, ob irgendjemand deine idee will.
aber du brauchst trotzdem geschmack.
du musst trotzdem entscheidungen treffen.
im grunde führst du regie beim produkt, während shipper es baut.
und die qualität des ergebnisses hängt stark von der qualität dieser entscheidungen ab.
der größte unterschied liegt darin, wie du mit der ki sprichst.
sag ihr nicht einfach „bau eine app“.
zwing sie immer wieder, an den nutzer zu denken:
- was sieht er zuerst?
- was muss er hier verstehen?
- was ist die einzelne wichtigste aktion?
- wie schnell erlebt er den hauptnutzen?
- wo könnte er verwirrt sein?
- welche informationen können wir streichen?
- was macht das hier befriedigend?
- was gibt ihm einen grund, die app morgen zu öffnen?
das führt meistens zu etwas viel besserem, als endlos nach neuen features zu prompten.
5) mach die erste version gut genug, um geld dafür zu verlangen
sobald das haupterlebnis funktioniert, hör auf, zufällige funktionen hinzuzufügen.
konzentriere dich auf drei dinge.
onboarding
behandle onboarding wie ein eigenes produkt.
denn für die meisten nutzer ist es genau das.
sie haben dein produkt noch nicht erlebt. sie haben keine loyalität zu dir. sie können die app in zwei sekunden schließen und nie wieder daran denken.
such gute onboarding-flows, mach screenshots davon und wiederhole denselben referenz-prozess.
dein ziel ist simpel:
der nutzer sollte innerhalb von 30 sekunden verstehen, warum er die app geladen hat, und wert erleben.
jeder onboarding-screen muss seine existenz rechtfertigen.
wenn du eine frage stellst, nutze die antwort.
wenn du nach einer berechtigung fragst, erklär warum.
wenn etwas bis später warten kann, verschieb es nach hinten.
und wenn du acht onboarding-screens hast, nur weil jede zweite consumer app acht onboarding-screens hat, machst du es falsch.
gib diese referenzen dann shipper und iteriere, bis sich das ganze ding selbstverständlich anfühlt.
monetarisierung
sobald das produkt funktioniert, füge dein abo und deine paywall hinzu.
diskutiere nicht drei tage darüber, ob dein jahresplan 27,99 $ oder 31,99 $ kosten soll.
du hast noch keine daten.
ein völlig normaler startpunkt könnte sein:
- 4,99 $/woche
- 29,99 $/jahr
preise kannst du später testen.
was anfangs wichtiger ist, ist wann du nach geld fragst.
lass den nutzer wenn möglich erst den wert verstehen.
lass ihn etwas erstellen.
ein ergebnis sehen.
seine erste session beenden.
seinen ersten personalisierten plan bekommen.
stell die paywall dann genau dorthin, wo er diesen wert fortsetzen will.
der nutzer soll denken:
„ich will mehr davon.“
nicht:
„wofür zum teufel zahle ich hier?“
polish
nutze die app dann.
viel.
starre nicht auf den homescreen und entscheide, dass er fertig aussieht.
verhalte dich wirklich wie ein nutzer.
starte mit einem frischen account.
tipp dinge in seltsamen reihenfolgen an.
verweigere berechtigungen.
schließ die app mitten im onboarding.
öffne sie wieder.
lass felder leer.
nutz absurde eingaben.
komm am nächsten morgen zurück.
gib sie freunden, ohne etwas zu erklären, und schau, wo sie hängen bleiben.
du wirst unfassbar viele winzige dinge entdecken, die für dich total sinn ergaben – weil du es gebaut hast.
jede verwirrende interaktion, die du entfernst, macht das produkt vertrauenswürdiger.
und wann immer sich etwas falsch anfühlt, geh zurück zu shipper und beschreib genau, was geändert werden soll.
du versuchst nicht, die erste version perfekt zu machen.
du versuchst sicherzustellen, dass sich der kern-loop fertig anfühlt.
6) veröffentliche, bevor du dich bereit fühlst
sobald der haupt-loop funktioniert:
VERÖFFENTLICHE ES.
verbring keinen weiteren monat damit, social features, achievements, ki-assistenten, custom themes und 14 einstellungen einzubauen, nur weil du angst vorm publishen hast.
die erste version soll nicht beweisen, dass du ein genie bist.
sie soll eine frage beantworten:
will das überhaupt jemand?
veröffentliche sie.
mach content über das problem.
schick leute dorthin.
schau, was sie tun.
lies die reviews.
schau, wo das onboarding abbricht.
schau, wie viele leute wirklich bis zur kernaktion kommen.
schau, wie viele am nächsten tag wiederkommen.
schau, wie viele eine woche später wiederkommen.
schau, wer zahlt.
repariere dann, was kaputt ist, und veröffentliche erneut.
ich persönlich würde mit ios anfangen und mir erst gedanken über android machen, wenn die idee den zusätzlichen aufwand verdient hat.
und ich würde die erste version fast schon schmerzhaft fokussiert halten.
eine zielgruppe.
ein problem.
ein versprechen.
ein kern-loop.
du kannst die app immer noch größer machen, wenn leute sie mögen.
etwas kleiner zu machen, nachdem du 30 features gebaut hast, ist viel schwerer.
das verrückte am bau von consumer apps gerade jetzt ist, dass die technische hürde, die die meisten von uns davon abgehalten hat, praktisch verschwunden ist.
früher hast du den größten teil deiner energie darauf verwendet, herauszufinden, wie du das ding baust.
jetzt kannst du viel mehr davon in die teile stecken, die das ding wirklich zum laufen bringen:
ein echtes verhalten finden.
es in ein produkt verwandeln, das leute sofort verstehen.
ihnen einen grund geben, zurückzukommen.
distribution klären.
du kannst auf tiktok herausfinden, was leute wollen, die apps studieren, die ihre aufmerksamkeit bereits gewinnen, diese muster in einen ordentlichen produkt-spec verwandeln und shipper das ding bauen lassen.
und es dann echten menschen zeigen.
du musst vor dem start nicht wissen, ob es eine 10k $/monat-app wird.
du musst nur version eins in die hände von jemandem bekommen.
am besten, bevor der 18-stunden-timer abläuft.
