Architecture sized to the team
What I learned picking an architecture for a small mobile team, where the patterns have to fit the people who will maintain them.
When I took on mobile development at my company, I felt illiterate at first. Simple bug fixes and small features were hard. Not because the problems were hard, but because of decisions made long before I arrived.
There was a single developer on the apps. Whenever an app needed an iOS version, its source code was duplicated. Every fix had to be made more than once, in code that had already started to drift apart. We reached a point where some changes would be cheaper if we started over.
The company gave us support and the freedom to find a better way. This is what I learned looking for it. Most of it comes down to one idea.
The right architecture is the one the team that maintains it can actually work with.
Two codebases cost more than double
One change, two codebases
With two native apps, every change is built, tested, reviewed and released twice, and the two have to be kept in sync. With one shared codebase, once.
For a small team I see no reason to keep two native codebases. Don't expect the work to double. It will be much more than double.
Every change is built, tested, reviewed and released twice. The two versions drift. A fix lands on one and is forgotten on the other. A feature ships on Android a month before iOS. Knowledge splits too. The person who knows the iOS code is rarely the one who knows the Android code, and on a small team that might be nobody.
A cross-platform framework removes most of that. For me that has been React Native. One codebase, one set of bugs, one place to fix them.
To be fair, if an app really needs the last bit of performance, two native apps might make sense. Even that is debatable, and it's rarely true of the apps a small team builds.
An architecture, not a big one
A small team probably has small apps. They don't need something as heavy as Clean Architecture or MVVM, with layers built for changes that never come.
But they do need some architecture. Without one, every developer solves the same problem a different way, and the codebase becomes a collection of personal styles.
Too much
- Layers on every screen, even the simple ones
- A pattern nobody on the team has used before
- Abstractions for changes that may never come
- Rules that live in one person's head
Enough
- A structure the market already knows
- Folders organized the same way everywhere
- One way to fetch data
- One way to manage state
- A short page explaining the choices
Prefer a structure that's known in the market. New developers find their way around faster, and you can hire people who already know it.
Fit the patterns to the people
Complex patterns land on the senior
One senior's week on a team of juniors. Illustrative, not measured.
Take a team with one senior developer and several juniors. Choosing complex patterns like Observer, which is a debugging nightmare, Clean Architecture and MVVM can quietly crush the senior. On top of their own work, they become tech lead and consultant for everyone, for long hours. The team slows down, and the juniors struggle with patterns they're still learning.
Simplifying here isn't lowering the bar. It means matching the complexity of the architecture to the team's experience, so less experienced people can contribute now and grow into the harder patterns later.
That growth doesn't happen on its own. Code review, pair programming and pull requests make it happen. They spread knowledge while the work is being done, and they move the explaining from the end of the day into the work itself.
When the team grows, or the juniors stop being juniors, revisit the choice. An architecture sized to the team should change size with it.
Simplifying isn't lowering the bar. It's sizing the architecture to the people who carry it.
Releases take longer than you think
A fix on the web ships today. A fix in an app waits.
From a fixed bug to users having the fix. Store review and slow updates keep a bug in production longer.
This sounds minor, and in a small team it isn't. On the web, a hotfix is routine. An app goes through store review, so a bug that reaches production stays there for a while, especially on the App Store. Even after the fix is approved, users update over days or weeks.
So the testing has to happen before the release.
- Number versions the same way on both platforms. Everyone knows which build they're talking about.
- Test in development. Run automated tests on every change.
- Test with real users before the release. TestFlight on iOS and closed testing on Google Play let a small group find what you missed.
Write it down
Document how the system should behave and why the architecture was chosen. It doesn't need to be long. A page a new developer can read on their first day is enough.
With one codebase, an architecture the team can carry, careful releases and a short document, I think most of the problems go away. Hiring gets easier too. The next person can learn the system from the code and that page, instead of from the one person who remembers it.
Build the architecture your team can carry today, and resize it when the team changes.