Bevor Sie den Rewrite beauftragen, bevor Sie das Team austauschen, bevor Sie Ihrem Dienstleister noch eine Chance geben — schauen wir gemeinsam, ob das Problem wirklich dort liegt, wo Sie es vermuten.
Was ich in App-Bewertungen immer wieder sehe — und warum die Lösung fast nie im einzelnen Bug-Fix steckt.
Muster 01
„Letztes Update bringt wieder nichts, ...“
Was das meistens bedeutet: Wenn die Bewertung trotz Feature-Releases sinkt, lösen Sie keine Nutzer-Probleme. Das ist ein Produkt-Problem — Sie setzen die falschen Prioritäten. Output (ausgelieferte Features) wird mit Outcome (was Nutzer erleben) verwechselt.
Was Teams stattdessen vermuten: „Wir liefern doch regelmäßig“ oder „Nutzer*innen sind nie zufrieden“. Beides verfehlt die Frage, ob die richtigen Sachen geliefert werden.
Muster 02
„Wenn wir X [Aktuelle Hype-Technologie einsetzen] nutzen würden, wäre es kein Problem.“
Was das meistens bedeutet: Rewrite-Entscheidungen entstehen oft aus Frustration, nicht aus Analyse. Rewrites sind fast nie die Silver Bullet, die alle Probleme löst. Dafür fühlt sich das Team für eine gewisse Zeit produktiv — danach kommen die gleichen Probleme wieder, weil dieselben Prozesse sie produzieren.
Was Teams stattdessen vermuten: „Die Architektur ist alt.“ Meistens ist nicht die Architektur das Problem, sondern das, was den Code über die Zeit in den aktuellen Zustand gebracht hat.
Muster 03
„Es funktioniert nicht — keine Ahnung warum.“
Was das meistens bedeutet: Wenn ein Bug nicht reproduzierbar ist, fehlt meistens der nötige Kontext vom Nutzer — und niemand hat die Disziplin, nachzufragen. Oder: das, was der Nutzer beklagt, wird gefixt, ohne dass jemand fragt, warum es überhaupt entstanden ist.
Was Teams stattdessen vermuten: „Lässt sich nicht reproduzieren“ oder „haben wir gepatcht“. Eigentlich fehlt der Prozess, Nutzer-Beschwerden in eine echte Hypothese zu übersetzen — und der Stop-Mechanismus, der verhindert, dass am nächsten Symptom gearbeitet wird, bevor das letzte verstanden ist.
Muster 04
„Seit dem letzten Update ist die App eine Katastrophe, geht immer wieder einfach aus, trotz Benutzung.“
Was das meistens bedeutet: Ein PM, der vor dem Release manuell durchklickt, ist kein QA-Prozess — das ist Hoffnung. Damit entstehen genau die Bugs, die später in 1-Sterne-Bewertungen stehen.
Was Teams stattdessen vermuten: „Der Fix war easy ... muss nicht durch QA“ oder „wir patchen schnell nach“. Eigentlich fehlt ein Release-Gate, das diese Klasse von Regressionen institutionell abfängt.
Muster 05
„Die Agentur sagt, das ist gefixt — aber die Bewertungen sind die gleichen.“
Was das meistens bedeutet: Ohne jemanden auf Ihrer Seite, der unabhängig einschätzen kann — ist der Code gut? Sind die Feature-Schätzungen fair? Dauert eine Änderung wirklich so lange, oder verdeckt der Aufwand nur, dass der Code-Stand jede neue Zeile teuer macht? — sind Sie Ihrem Partner ausgeliefert. Vertrauen ohne Prüfung ist eine Wette.
Was Teams stattdessen vermuten: „Das fixt sich beim nächsten Sprint“ oder „wir vertrauen unserem Partner“. Eigentlich fehlt die Mobile-Tiefe in der eigenen Organisation, um Aussagen zu Code, Aufwand und Timelines einzuordnen.
„Code entsteht aus Entscheidungen davor und lebt durch QA, Support und Feedback danach. Devs sind selten das einzige Problem.“
Was Ihre Nutzer*innen wirklich brauchen, nicht was Ihre Roadmap sagt. Intern und extern werden die Wünsche an Sie herangetragen. Hören Sie zu?
Wie können Nutzer*innen Ihre Feature-Wünsche einbringen?
Mobile-Software bricht selten dort, wo die Tests laufen — sie bricht auf Geräten, die niemand im Team besitzt. Nach 15 Jahren Android kenne ich die Bug-Klassen, die immer wiederkommen, und die Wege durch Features, für die die Plattform keinen offiziellen Pfad anbietet.
Welchen Bug haben Sie in den letzten sechs Monaten dreimal gefixt — ohne ihn jedesmal wirklich verstanden zu haben?
Die meisten App-Probleme sind Organisations-Probleme. Prozesse, die man gelesen und implementiert hat, ohne zu Verstehen, warum sie bei anderen funktionieren, und was im eigenen Kontext anders ist.
Ihre Features drehen ständig Schleifen zwischen Produkt, Entwicklung und QA?
Bisherige Kunden: DAK Gesundheit, Otto, Audi, Daimler, Freeletics, ARD Online und eDarling.
Gebucht für:
Code- und Produkt-Review der App eines Otto-Tochterunternehmens, gebaut von einer externen Agentur. Damals war ich Senior Android Dev im internen Mobile-Team der Otto Group — die Produktmanager*innen der Tochter kamen zu uns, weil sie ein Mobile-Team brauchten, dem sie uneingeschränkt vertrauen konnten.
Was mir auffiel:
Es war keine Frage der Agentur-Kompetenz — es war die Asymmetrie. Auf der Auftraggeberseite saß niemand, der Code, Architektur oder Aufwandsschätzungen einordnen konnte. Auf diesem Boden waren die strukturellen Probleme gewachsen, die die PMs spürten, aber nicht benennen konnten: keine klare Architektur, alles hing von allem ab, neue Features brachen regelmäßig ältere.
Was sich veränderte:
Wir hielten Beobachtungen und Empfehlungen in mehreren Wiki-Seiten fest. Die Agentur übernahm einen Teil davon. Wichtiger als das Dokument war die neue Balance: die PMs hatten jetzt Vokabular, Maßstäbe, eigene Hypothesen. Die Agentur wusste, dass jeder Aufwand und jede Empfehlung im Detail eingeordnet werden konnte. Die Beziehung wurde nicht beendet — sie wurde gesünder. „Es wurde besser.“
Gebucht für:
Beratung mit Option auf CTO-Rolle, falls die Zusammenarbeit passt. In der Praxis: Aufbau eines internen QA-Prozesses und einer Fallback-Version des MVP — damit das Startup nicht vollständig von einem extern verordneten Dev-Team abhängig war.
Was mir auffiel:
Der Gründer war in der Wahl seines Dev-Teams nicht frei: der Investor hatte ein befreundetes Offshore-Team gesetzt, und das Team lieferte nicht. Das eigentliche Problem war nicht technisch, sondern strukturell — eine Lieferabhängigkeit, die niemand intern reparieren konnte, weil der Vertrag schon stand. Was fehlte: jemand auf der Startup-Seite, der unabhängig bewerten konnte, wie schlecht es wirklich lief.
Was sich veränderte:
Mit dem internen QA-Prozess und der Fallback-MVP-Version hatte das Startup zum ersten Mal echte Verhandlungsmacht gegenüber dem Offshore-Team. Am Ende blieb der Gründer dennoch beim Setup seines Investors — eine politische Entscheidung, keine technische. Was bleibt: der Hebel, den ich aufgebaut habe, ist genau das, was ein Fractional Expert leistet, wenn die Vendor-Wahl nicht frei ist.
Gebucht für:
Mitwirkung an einem laufenden Rewrite einer Smart-Lock-App (Kotlin, Jetpack, BLE, Azure DevOps CI/CD) — speziell für die BLE-Schichten, in denen die nötige Tiefe im Team fehlte.
Was mir auffiel:
Die Entscheidung für den Rewrite war intern bereits gefallen — und richtig. Das Team wusste, was es wollte. Was fehlte, war Spezialwissen in einem schmalen, aber kritischen Bereich: Bluetooth-Low-Energy auf Android im Verhalten echter Hardware. Ohne diese Tiefe wäre der Rewrite an genau den Stellen hängen geblieben, die ihn überhaupt rechtfertigen.
Was sich veränderte:
Rewrite ausgeliefert. Der Fall zeigt, was ein Fractional Expert leistet, wenn ein Team einen klaren Plan hat, aber eine spezifische Tiefe punktuell braucht — keine Architektur-Beratung von außen, sondern die fünfzehn Jahre BLE-Praxis, die intern fehlten, eingebettet in den Sprint.
Gebucht für:
Entwicklung einer kompletten Android-App für ein Medical-/Vital-Daten-Startup: BLE-Sensor-Anbindung, UX/UI-Verantwortung, End-to-End — vom Hardware-Dialog bis zur Play-Store-Veröffentlichung.
Was mir auffiel:
Das war keine Fractional-Expert-Konstellation — das war E2E-Verantwortung über zwei Jahre. Aber genau deshalb gehört der Fall hierhin: er zeigt, dass das, was ich heute als Fractional Expert empfehle, aus tatsächlich ausgelieferter Erfahrung kommt, nicht aus Folien.
Was sich veränderte:
Produkt ausgeliefert. Was bleibt: jede Empfehlung, die ich heute zu Architektur, BLE, Sensor-Dialogen oder Medical-Anforderungen gebe, kommt aus einem Projekt, in dem ich diese Entscheidungen selbst tragen musste — nicht aus einer Vendor-Bewertung.
Wenn Sie intern entwickeln:
Sie haben Entwickler*innen. Sie liefern regelmäßig. Aber Ihre Bewertung sinkt, Ihre Nutzer*innen sind frustriert, und Sie ahnen, dass das Problem nicht (nur) im Code steckt. Sie brauchen jemanden, der das ganze System sieht — Produkt, Technik, Organisation.
Wenn Sie mit einer Agentur oder einem Dienstleister arbeiten:
Ihre Agentur baut und pflegt Ihre App. Ihr PM klickt jede Release durch und hofft das Beste. Sie können nicht einschätzen, ob der Code gut ist, ob die Architektur skaliert oder ob „das wird im nächsten Sprint gefixt“ stimmt. Sie brauchen einen unabhängigen Experten auf Ihrer Seite.
Nicht das Richtige, wenn:
Sie wollen eine Agentur, die von Null baut, oder Sie wollen Ihr Engineering-Team ersetzen. Falls Sie pre-launch sind: Founder-Sparring liegt mir — aber es ist nicht der Scope dieses Angebots. Sprechen Sie mich gerne separat an.
Kostenlos, 15 Minuten, ohne Vorbereitung Ihrerseits. Ich höre zu, wir sortieren, ob es Sinn ergibt weiter zu reden. Wenn ja, sprechen wir darüber, was als nächstes sinnvoll ist.
Erstgespräch buchen30-Minuten-Gespräch, in dem wir klären, ob eine 1-Wochen-Diagnose das Richtige für Ihre Situation ist. Mehr zur Methodik auf der Diagnose-Seite.
Diagnose besprechen5–30 Stunden pro Woche, in enger Zusammenarbeit mit Ihrem Team — Umfang passt sich der Projekt-Phase an, monatlich nachjustierbar. Für Situationen, in denen die Richtung schon klar ist und es um die laufende Begleitung geht.
Direkt einen Retainer besprechenLieber erst schreiben? steven.mohr@smartasapps.de
Noch unsicher? Schicken Sie mir Ihre App ↗
Über mich
Seit 2014 Geschäftsführer der Smart As Apps GmbH. 15+ Jahre Android, 20+ Apps ausgeliefert.
M.Sc. Informatik FU Berlin (Schwerpunkt Software-Prozesse; Nebenfach Organisationspsychologie). DHBW Mannheim B.Eng. IT. DroidCon-Sprecher (Berlin 2016, 2018). TÜV-Rheinland-Dozent (2024). Google Summer of Code 2008.
Aktuell AI-native Mobile-Entwicklung mit Claude Code — sowohl in Kundenprojekten als auch in eigenen Side-Projects.
Ein Fractional Mobile Expert ist eine Senior-Mobile-Kraft, die Sie stundenweise oder tageweise einkaufen — nicht als Vollzeit-Anstellung, nicht als Agentur. In meinem Fall: 5–30 Stunden pro Woche im Retainer, in enger Zusammenarbeit mit Ihrem Team, mit Fokus auf Produkt, Technik und Organisation Ihrer Mobile-Projekte.
Eine Agentur liefert Durchsatz. Ein fester Entwickler liefert Kontinuität. Ein Fractional Mobile Expert liefert unabhängiges Senior-Urteil — besonders, wenn Sie kein internes Mobile-Management haben, aber Ihre App-Entscheidungen stark sind, sollten Sie jemanden haben, der die Qualität der Arbeit bewerten kann.
Entweder eine einmalige 1-Wochen-Diagnose (Vorbereitungswoche plus 5 Tage, Festpreis, schriftliche Analyse) oder ein fortlaufender Retainer (5–30 Stunden/Woche, monatliche Pauschale, Umfang monatlich anpassbar). Viele Kunden starten mit der Diagnose und entscheiden anschließend, ob sich ein Retainer lohnt.
1-Wochen-Diagnose: 5.000 € vor Ort, 4.500 € remote (Festpreis). Retainer: monatliche Pauschale je nach vereinbartem Umfang (5–30 Stunden/Woche). Reise innerhalb Deutschlands ist in der Diagnose enthalten; außerhalb nach Vereinbarung.
Vorbereitungswoche plus 5 Tage: Workshop, Code-Review, Interviews, Debrief — am Ende eine schriftliche Analyse (ca. 5–10 Seiten) mit beobachteten Mustern, Ursachen und priorisierten Empfehlungen. Details zur Methodik ↗
Die Diagnose reicht, wenn Sie primär Klarheit wollen — z.B. vor einem großen Budget-Move (Rewrite, Team-Umbau, Vendor-Wechsel). Ein Retainer lohnt sich, wenn die Diagnose gezeigt hat, dass die Probleme strukturell sind und über Monate begleitet werden müssen, nicht in einem Bericht gelöst.
Ja, das ist sogar eine meiner häufigsten Konstellationen. Wenn Sie mit einer Agentur arbeiten, bin ich der unabhängige Experte auf Ihrer Seite, der bewerten kann, ob das, was Sie bezahlen, tatsächlich gut ist. Die Diagnose ist dafür gebaut.
Ja. Das ist genau der Otto-Group-Fall, den ich oft mache: Code- und Produkt-Review dessen, was eine externe Agentur baut, als schriftliche Analyse, die Sie in Vendor-Gesprächen einsetzen können. Ziel ist selten Vertrags-Kündigung — Ziel ist meistens, die Beziehung gesünder und produktiver zu machen.
Dann sage ich Ihnen das im Klartext. Aber: die Antwort ist selten „Agentur kündigen“. Meistens lassen sich Agentur-Beziehungen mit strukturellen Änderungen reparieren — klarere Anforderungen, besserer Release-Prozess, regelmäßige unabhängige Reviews. Genau das war der Otto-Group-Fall: die Analyse hat die Beziehung gesünder gemacht, nicht beendet. Die Analyse gibt Ihnen die Grundlage, die Entscheidung selbst zu treffen — auf Basis von Fakten, nicht Emotion.
Mit den Basics beginnen. Viele Teams haben nicht einmal die Grundausstattung an automatisierten Tests — da liegt oft der größte Hebel. Für die kritischsten Features setzen wir automatisierte Tests auf; wo Automatisierung nicht sinnvoll ist, definieren wir klare Test-Pläne. Tooling, das fehlt, kommt dazu.
Ja. Produkt-, Prozess- und Organisations-Themen sind plattform-agnostisch — das ist der Großteil meiner Arbeit. Auf plattform-spezifischer Code-Ebene ist Android (12+ Jahre) mein Schwerpunkt; für iOS-Tiefen arbeite ich mit einem spezialisierten Kollegen zusammen, wo nötig.
Genau deshalb. KI-Agenten produzieren erstaunlich guten Code — aber sie können nicht entscheiden, was gebaut werden soll, wann ein Feature gestoppt werden muss, oder ob das, was „funktionierend“ aussieht, tatsächlich das richtige Ergebnis liefert. Je mehr Code von KI kommt, desto wichtiger werden zwei Dinge: erstens, Senior-Urteil darüber, was überhaupt gebaut werden soll (Produkt, Prioritäten, Architektur). Zweitens, ein wirklich solider Release- und Review-Prozess, der KI-Output diszipliniert — denn KI generiert plausibel aussehenden Code, der trotzdem falsch sein kann. Beides ist genau das, was ich als Fractional Mobile Expert mitbringe. Mein Job wird mit jedem KI-Tool relevanter, nicht weniger.
Aktuell arbeite ich z.B. für einen Stealth-Startup im Gesundheitsbereich als AI-native Developer: Lovable-Prototypen werden mittels Claude Code zu wartbarer Produktions-Software, neue Features werden in Zusammenarbeit zwischen mir und KI-Tools gebaut und getestet, das Team wird zu regulatorischen Anforderungen für Medizin-Software beraten. Dazu habe ich 2024 für die TÜV Rheinland Academy mehrere Tages-Seminare zu „Generative AI in software development“ gehalten. Aus dieser Praxis lerne ich täglich, welche Disziplin nötig ist, damit KI-generierter Code nicht zu derselben Klasse von Bewertungs-Problemen wird, die in den fünf Mustern oben beschrieben sind. Diese Erfahrung fließt in jede Retainer-Begleitung ein — Teams, die ich begleite, lernen nicht nur Mobile-Disziplin, sondern auch, wie sie KI-Tools so einsetzen, dass die Qualität steigt und nicht sinkt.
Nein. Wenn das Ergebnis einer Diagnose oder eines Retainers ein Rebuild durch meine eigene Agentur wäre, hätte ich an dem gescheitert, wofür ich da bin: Ihr Team oder Ihren bestehenden Dienstleister so zu unterstützen, dass die Probleme nicht wiederkommen. Ein Rebuild durch mich wäre der teuerste und langsamste Weg, das gleiche organisatorische Problem zu reproduzieren. Mein Job ist, dass Sie mit den Leuten, die Sie schon haben, gut ausliefern können.
Ja, aber nicht durch ein Agentur-Team, das Ihres ersetzt. Skalierung läuft bei mir über zwei Wege: Erstens Coaching Ihres bestehenden Teams, damit es schneller und mit weniger Reibung liefert. Zweitens gezieltes Einbringen von Freelance-Spezialist*innen für konkrete Lücken — Entwicklung (iOS, AR, BLE, Spezial-Hardware), UI/UX-Design oder QA — als Ergänzung Ihres Teams, nicht als Ersatz. So wächst Ihre eigene Lieferfähigkeit, statt dass Sie noch eine Vendor-Abhängigkeit aufbauen.
Details zur Datenverarbeitung auf dieser Website stehen in der Datenschutzerklärung. Kurz: auf /einschaetzung nutze ich das EU-gehostete Formular von Tally; Ihre Einsendung bekomme ich per E-Mail; die Daten werden für die Bearbeitung Ihrer Anfrage verwendet und nach Abschluss gemäß Datenschutz gelöscht.