Agency Review at Otto Group.

The starting point

At the time I was a Senior Android Dev on Otto Group's internal mobile team. We built a white-label solution for the e-commerce apps of several group companies — Sheego, MyToys, and others. Small and fast: two Android devs, two iOS devs, with the goal of shipping an app for each group company in about four weeks.

One joint venture within the group had its own e-commerce app at the time, built by an external agency. It predated our white-label solution and had been running with that agency for almost two years. Progress was fast at first — by now, problems were piling up. The group company's product managers approached our mobile team and described four observations: "Bugs are piling up." "Features are getting delayed." "The app feels slow." "Shopping works worse in the app than on the mobile website."

They didn't come to us because they wanted to get rid of the agency. They came because they lacked someone who could put the agency's statements into context — an expert team that builds similar apps and that they could trust without reservation.

What I found

We started with a workshop with the product managers, then a half-day on-site at the agency: a code tour, walking through the architecture together, questions — why this library, why this separation, why this release process. The agency gave us repo access; we did the actual review remotely. I took the Android side, a colleague from the mobile team took the iOS side.

The pattern was the same on both platforms: no discernible architecture, everything depended on everything. New features regularly broke older ones. Error handling was missing in many places — a failure in one component would contaminate the entire app state.

Three of the four observations from the kickoff were explained directly by this. "Bugs are piling up" and "features are getting delayed" are the inevitable symptoms of code like this. "The app feels slow" had an additional, structural cause. That's where the leverage for our most important recommendation was.

The analysis

We documented the results across several wiki pages: code and architecture observations, their causes, prioritized recommendations for the agency, and a proposal for how an e-commerce app on Android and iOS could be structured better.

The structural part came from our own practice. E-commerce apps are usually built around the webshop, with lots of webviews — and webviews are slow, especially on the pages where users spend a lot of time: search, search results, categories, product listings. In our white-label solution, we had replaced exactly these pages with native views, fed by a specialized API between the app and the webshop. Result: most of the user journey runs natively, with the speed and UX users expect from an app — and conversion goes up, because the app feels better than the mobile website, not worse.

That was the answer to both "the app feels slow" and "shopping works worse in the app than on the mobile website" at the same time. And it wasn't a theoretical recommendation — it was an approach we already had in production in our own apps.

What changed afterward

The agency adopted some of the recommendations. Not everything — some would have required a refactoring that wasn't possible mid-sprint. But enough that the relationship between the group company and the agency changed.

We had discussed and dismissed the obvious alternative — migrating the group company from the agency setup to our white-label solution. The app had too many custom features we would have had to rebuild. That would have been a long road back to the status quo before anything actually got better.

But the document wasn't the real outcome. The real outcome was: the product managers now had vocabulary, benchmarks, and their own hypotheses about what was technically realistic and what wasn't. And above all, the agency now knew that the joint venture had a mobile team beside it that could scrutinize every estimate and every recommendation in detail. The asymmetry — the agency knows everything, the client knows nothing — was the ground the original problem had grown from in the first place. That asymmetry was gone now.

What the product managers told me later: the agency put in effort differently. Estimates got phrased more carefully. "That's not possible right now" disappeared from the conversations. I don't have hard numbers from that time. What I have is what the PMs said: "It got better."

Why I tell this story so often

When I talk to companies today whose app is built by an external agency, I often hear a similar setup: no deep mobile expertise in-house, the same agency for a few years, a growing gut feeling that something's off — and no way to translate that gut feeling into a statement you can actually negotiate with.

The obvious reaction in this situation is to replace the agency or rebuild the app. Both are almost always more expensive and slower than they look. By the time a new setup gets you back to where you already are today, you'll have spent money and time without anything getting better for your users. Worse: from a user's perspective, a rewrite phase looks exactly like a neglected app — no new features, fewer bug fixes, the sense that the developers have stopped listening. Both the cost and the lost user trust have to be paid back before the new setup even starts to pay off.

My job back then on the mobile team and my job today as a Fractional Mobile Expert are the same: making sure the right question gets asked before someone sinks a lot of money into a rebuild or a vendor switch. Often the most honest answer is: the existing setup can be fixed. This case was the proof.