HUGO BOSS — bringing global Android apps in-house
Problem
The BOSS and HUGO apps ship to customers in fifteen countries and eight languages, with more than 500,000 installs on Google Play. They carry e-commerce, click-and-collect, in-store appointments and the HUGO BOSS XP loyalty programme.
They were built and operated by an external agency. That arrangement works until the app becomes central to the business, and then every question about it — what gets built next, how quickly, what the code looks like underneath — has to travel through a contract before it can be answered.
Constraint
The apps were live commerce in fifteen markets throughout the transition. Bringing development in-house could not mean a pause, a rewrite, or a quarter of degraded delivery. The handover had to happen underneath a running business, and the team receiving the codebase did not exist yet.
Decisions
- Insource first, improve second. Take ownership of the codebase exactly as it stood rather than treating the handover as licence for a rewrite. A rewrite would have been the most satisfying decision available and the one most likely to end the programme early.
- Build the internal Android team from zero — hiring, onboarding, and the working agreements a brand-new team needs before it can move at all.
- Write the conventions down. Coding standards, architecture patterns, workflows, way of working. With a new team and an inherited codebase, tacit knowledge is not available to lean on: making the conventions explicit is what let people make correct decisions without a senior engineer present for each one.
- Modernize under delivery, not instead of it, so the app could keep absorbing e-commerce, click-and-collect, in-store appointments and loyalty features while the base was being brought up to current standards.
- Break the single module apart, then wire it with dependency injection. The app arrived as one module. I re-architected it into many and introduced dependency injection through the data and business layers. That bought two things that are hard to get any other way. The app's behaviour could change per country by swapping an implementation, with no rewiring of the UI. And every layer became mockable in plain Kotlin, with no third-party mocking library — so unit tests could run in parallel, faster, and without the flakiness that shared test infrastructure produces.
Result
Development moved from agency delivery to an internal team, on apps that stayed live in fifteen markets throughout.
The clearest signal that the work outlived the project: the conventions, architecture patterns and way of working defined for Android were adopted by management across the whole mobile organization. The codebase was modernized to current engineering standards so that e-commerce, click-and-collect, in-store appointments and the HUGO BOSS XP loyalty programme could scale with the business rather than against it.
The test suite went from nothing to roughly 70% coverage in twelve months. That number is what the rest rests on: fewer defects reaching production, a more stable app, and a product team that could try something and find out whether it worked without waiting on a manual regression pass.
What I'd do differently
I would write the conventions before the handover, not after it. We took ownership of the codebase first and documented the way of working while the team was still forming, which meant the earliest hires were deciding things before there was anything written down to decide against. Those conventions ended up being what management adopted across the whole mobile organization — they were worth more than their place in the sequence suggested, and they should have been the first artefact of the insourcing rather than a product of it.