Lately I’ve been thinking a lot about architecture.
Not from a theoretical point of view, but from something more practical:
why we often end up overcomplicating apps that don’t really need it.
Because if there’s one thing that happens a lot in mobile, it’s this:
we use architectures designed for large systems… in apps that aren’t there yet.
The problem is not the architecture
Architectures like Clean Architecture, MVVM, or similar approaches are not the problem.
They exist for a reason.
The real issue is when and how we use them.
Because many times, we don’t apply them out of necessity…
We apply them because “it’s the right thing to do”.
When everything starts scaling (for no reason)
You start with a simple app.
A couple of screens, some logic, a few network requests.
And suddenly you have:
- Use cases
- Repositories
- Data sources
- Mappers
- DTOs
- Domain models
Everything nicely separated.
Everything looks clean.
But also…
much more complex than the app actually needs.
The invisible cost
That extra complexity isn’t free.
You pay for it with:
- More code to maintain
- More time to make changes
- More friction to understand the flow
And worst of all:
more distance between the idea and the implementation
So… should we avoid architecture?
Not really.
Architecture is necessary.
But it should come as a response to a problem, not as a starting point.
A simpler way to think about it
Instead of asking:
“Which architecture should I use?”
A better question might be:
“What problem am I trying to avoid?”
- Frequent changes in logic → introduce abstraction
- Multiple data sources → separate layers
- Growing complexity → structure things better
If there’s no real problem…
you probably don’t need that much architecture yet.
What changes with experience
Over time, you start to notice a pattern:
The best architectures are not the most “correct” ones.
They are the ones that:
- are easy to understand
- allow you to iterate quickly
- don’t get in your way
The balance
No structure → chaos
Too much architecture → rigidity
The interesting part is in the middle.
And there’s no exact formula.
Final thought
Good architecture is not about adding more layers.
It’s about making things easier to change.
And many times, the simplest solution is already the right one.
The hard part is knowing when to stop.
Overengineering is not about writing more code.
It’s about solving problems you don’t have.
Top comments (2)
Great post on Architecture! Especially on the part:
It's always a good idea to have a balance as well, no one more than the other. I haven't got to the part where the architecture gets complex for me, but it is something to think about before and during the project build.
Great work btw!
Thanks a lot, I really appreciate it!
Yeah, that balance is definitely the tricky part. And honestly, it’s great that you’re already thinking about it now that makes a huge difference later on.
In my experience, the complexity doesn’t hit all at once, it kind of builds up over time. So being aware of it early is already a really good sign.
You’ll definitely run into it at some point, and when you do, this kind of mindset helps a lot.
Glad the post was useful 💪!