Before you commission a rewrite or replace the team, let's look together at whether the problem is really where you think it is.
Past clients (among others)
What I keep seeing in app reviews — and why the solution is almost never a single bug fix.
Pattern 01
„Another update that changes nothing, ...“
What this usually means: If your rating keeps falling despite shipping features, you're not solving user problems. That's a product problem — you're prioritizing the wrong things. Output (shipped features) gets mistaken for outcome (what users actually experience). Whether the right things are being delivered usually stays an open question.
Pattern 02
„If we used X [current hype technology], this wouldn't be a problem.“
What this usually means: Rewrite decisions often come from frustration, not analysis. Rewrites are almost never the silver bullet that solves everything. The team feels productive for a while — then the same problems come back, because the same processes produce them. Usually the architecture isn't the problem; what put the code in that state over time is.
Pattern 03
„It doesn't work — no idea why.“
What this usually means: When a bug isn't reproducible, the necessary context from the user is usually missing — and nobody has the discipline to ask for it. Or: what the user complains about gets fixed without anyone asking why it happened in the first place. What's actually missing is a process to translate user complaints into a real hypothesis, and a stop mechanism that prevents the team from moving to the next symptom before the last one is understood.
Pattern 04
„Since the last update the app is a disaster, keeps just shutting down, even while in use.“
What this usually means: A PM manually clicking through the app before release isn't a QA process — it's hope. That's exactly how the bugs that end up in 1-star reviews get created. What's missing is a release gate that catches this class of regression institutionally.
Pattern 05
„The agency says it's fixed — but the reviews look the same.“
What this usually means: Without someone on your side who can judge independently — is the code good? Are the feature estimates fair? Does a change really take that long, or does the effort just mask the fact that the current state of the code makes every new line expensive? — you're at your vendor's mercy. Trust without verification is a bet. What's actually missing is mobile depth inside your own organization to put claims about code, effort, and timelines into context.
„Code is born from the decisions before it and lives through QA, support, and feedback after it. Developers are rarely the only problem.“
What your users actually need, not what your roadmap says. Requests come at you from inside and outside the company. Are you listening?
How can users submit their feature requests to you?
Mobile software rarely breaks where the tests run — it breaks on devices nobody on the team owns. After 15 years of Android, I know the bug classes that keep coming back, and the workarounds for features the platform offers no official path for.
Which bug have you fixed three times in the last six months — without ever really understanding it?
Most app problems are organizational problems. Processes that got read about and implemented without understanding why they work elsewhere, and what's different in your own context.
Do your features keep looping between product, development, and QA?
If you develop in-house:
You have developers. You ship regularly. But your rating is falling, your users are frustrated, and you suspect the problem isn't (only) in the code. You need someone who sees the whole system — product, technology, organization.
If you work with an agency or vendor:
Your agency builds and maintains your app. Your PM clicks through every release and hopes for the best. You can't tell whether the code is good, whether the architecture scales, or whether “that'll be fixed next sprint” is actually true. You need an independent expert on your side.
Not the right fit if:
You want an agency to build from scratch, or you want to replace your engineering team. If you want to set up a new app the right way from the ground up: that's what the App Kickoff is for — a dedicated offer for exactly that starting phase.
Offers
Every offer has a clear scope, a fixed price, and a defined outcome. The first appointment is the start of the work, not a hurdle before it.
Before you start
For your live app
Does your procurement need a formal proposal? You'll get one in advance — with a service description and fixed price. Payment by invoice.
Free, 15 minutes, no preparation needed on your end. I listen, we figure out together whether it's worth continuing. If it is, we talk about what a sensible next step looks like.
What happens in the intro call ↗
Book an intro callThe fastest first step — no appointment needed:
What your app reviews are really saying — in plain terms, with Klartext. Free and without an appointment: the AI analysis shows the recurring patterns in your store reviews.
Analyze app reviewsAbout me
Managing director of Smart As Apps GmbH since 2014. 15+ years of Android, 20+ apps shipped.
M.Sc. Computer Science, FU Berlin (focus on software processes; minor in organizational psychology). B.Eng. IT, DHBW Mannheim. DroidCon speaker (Berlin 2016, 2018). TÜV Rheinland instructor (2024). Google Summer of Code 2008.
Currently working on AI-native mobile development with Claude Code — both in client projects and in my own side projects.
A Fractional Mobile Expert is a senior mobile professional you bring in by the hour or day, not as a full-time hire and not as an agency. In my case: 5–30 hours per week on retainer, in close collaboration with your team, focused on the product, technology, and organization of your mobile projects.
An agency delivers throughput, a full-time developer delivers continuity, a Fractional Mobile Expert delivers independent senior judgment. That's worth it especially when you have no internal mobile management but a lot rides on your app decisions: then you need someone who can judge the quality of the work being delivered.
Either as a one-off 1-Week Diagnostic (a prep week plus 5 days, fixed price, written analysis) or as an ongoing retainer (5–30 hours per week, monthly flat fee, adjustable monthly). The Diagnostic week is enough if you mainly want clarity, for example before a rewrite, a team restructuring, or a vendor change. A retainer makes sense when the problems are structural and need support over months. Many clients start with the Diagnostic week and decide afterward.
1-Week Diagnostic: €5,000 on-site, €4,500 remote. App Kickoff: €5,000. Second Opinion: from €1,490. AI Review Gate: €2,490 setup, optional €390/month Care Plan. Stability Sprint: from €2,900. Emergency App Rescue: from €1,490. All prices excl. VAT and fixed. Retainer: monthly flat fee depending on scope (5–30 hours per week). Travel within Germany is included for the Diagnostic week, outside Germany by arrangement. On request, you'll receive a formal proposal with a service description in advance.
Yes, that's one of my most common situations. If you work with an agency, I'm the independent expert on your side who can judge whether what you're paying for is actually good. You get a code and product review as a written analysis you can use in vendor conversations. The goal is rarely termination, usually a healthier and more productive collaboration with the agency. The Diagnostic week is built for exactly that.
Then I'll tell you plainly. But the answer is rarely "fire the agency." Most of the time the relationship can be repaired with structural changes: clearer requirements, a better release process, regular independent reviews. That's exactly what happened at Otto Group: the analysis made the relationship healthier, not over. You make the decision yourself, based on facts instead of gut feeling.
With the basics. Many teams don't even have the baseline set of automated tests; that's often where the biggest leverage is. For the most critical features, we set up automated tests; where automation doesn't make sense, we define clear test plans. Missing tooling gets added along the way.
Yes. Product, process, and organizational topics are platform-independent, and that's the bulk of my work. At the code level, Android — with over 12 years of experience — is my focus; for iOS depth, I work with a specialized colleague where needed.
Precisely because of that. AI agents write surprisingly good code, but they don't decide what should get built, when a feature needs to be stopped, or whether the result is actually the right one. The more code comes from AI, the more important senior judgment about product, priorities, and architecture becomes — along with a release and review process that catches AI code that looks plausible but is wrong. Both are exactly what I bring. Concretely: at a stealth healthcare startup, I'm turning Lovable prototypes into maintainable production software with Claude Code, and since 2024 I've been teaching TÜV Rheinland seminars on generative AI in software development.
No. If the outcome of a Diagnostic week or a retainer were a rebuild by my own agency, I would have failed at what I'm actually there for: supporting your team or your existing vendor so the problems don't come back. A rebuild by me would be the most expensive and slowest way to reproduce the same organizational problem. My job is to make sure you can ship well with the people you already have.
Yes, but not through an agency team replacing yours. Either I coach your existing team so it delivers faster and with less friction, or I bring in freelance specialists for specific gaps, as a complement to your team, not a replacement. That way your own delivery capability grows, instead of you building another vendor dependency.
I use your data to process your request and delete it after completion in line with data protection requirements. Details are in the privacy policy.