Android Architecture Review – an architecture that holds for the next five years
A deep review of how your Android app is built, with a concrete target architecture and a migration plan your team can follow without pausing feature delivery.
Get in touchCommon signs the architecture is slowing you down
- The team disagrees on how new features should be built and every pull request turns into a debate.
- A change in one place causes unexpected failures somewhere else.
- Views and Compose coexist in the same app with no clear rule for which to use.
- State handling is hard to follow and bugs cannot be reproduced.
- Tests are slow, flaky or missing because the code is hard to test.
- Several teams work in the same monolith and block each other.
When is an architecture review the right move?
What is included
- Review of current layering, modules and dependency directions.
- Assessment of state management, unidirectional data flow and Kotlin coroutines/Flow usage.
- Compose strategy: migration order, coexistence with Views, design system and reuse.
- A modularisation plan with clear interfaces and ownership per module.
- Testability: unit tests, UI tests, the test pyramid and build-time impact.
- Offline behaviour, synchronisation, error handling and the data layer where relevant.
- Ways of working: code standards, review routines, definition of done.
What you get
An architecture document covering the current state, the target state, the reasoning behind each choice and its trade-offs, plus a stepwise migration plan where every step is independently shippable. Optionally a reference implementation of one vertical slice the team can copy the pattern from.
Timeline and way of working
An architecture review normally takes one to two weeks including workshops with the team. The work is remote, with one or two workshops where the target picture is shaped together – team buy-in is what makes the plan survive everyday delivery.
Frequently asked questions
Do you push one particular architecture?
No. The choice follows the size of the app, the shape of the team and how often you release. The starting point is Google’s recommended architecture, adapted to your reality rather than to a template.
Do we have to migrate everything to Jetpack Compose?
No. Compose and Views can coexist for a long time. The usual recommendation is to build new screens in Compose and migrate existing ones when they need changing anyway.
Can you help us execute the plan too?
Yes, either as ongoing expert support for the team or by driving the first steps myself and setting the pattern the team then follows.
How do you approach multi-module projects?
Module boundaries follow feature and ownership rather than technical layer. The plan accounts for build times, the dependency graph and how the teams actually work.
How is this different from a Health Check?
A health check answers how the app is doing today across the full breadth. An architecture review goes deep on structure and delivers a target picture and a plan forward.
Does this cover automotive and embedded Android?
Yes. I have worked with Android in the automotive industry and with system-level development down to driver level, which places different demands on architecture than a consumer app.
Need a technical target picture to align around?
Describe the app and the team and I will propose a setup for the review.
Get in touch