There are a lot of opinions about how mobile apps should be built.
Frameworks, architectures, best practices… everyone has a take.
But over time, I realized something:
Building apps is less about following rules
and more about making good decisions.
So instead of talking about “the right way,”
this is how I personally think about building mobile apps today.
Start simple (really simple)
It’s very tempting to start with a full structure:
- Clean architecture
- Multiple layers
- Abstractions everywhere
But most apps don’t need that on day one.
What they need is:
- To work
- To be understandable
- To be easy to change
So I start simple.
And only add complexity when it’s justified.
Structure follows problems
I don’t decide architecture upfront anymore.
Instead, I let the app push me toward structure.
- If logic starts repeating → I extract
- If data sources grow → I separate
- If things get hard to maintain → I refactor
Architecture becomes a response.
Not a starting point.
State is the real challenge
Screens are easy.
State is not.
Most of the complexity in mobile apps comes from:
- Loading
- Errors
- Partial data
- User actions
- Sync
So I spend more time thinking about:
how state flows through the app
than how folders are organized.
The network will fail (plan for it)
Every feature I build has this question behind it:
what happens if this fails?
Because it will.
So instead of assuming success, I design for failure:
- retries
- fallbacks
- clear error states
That alone improves the app more than most patterns.
Don’t fight the platform
This is something I value more and more.
Native platforms exist for a reason.
So instead of trying to abstract everything:
- I embrace platform conventions
- I keep UI native
- I share only what makes sense
That’s why approaches like multiplatform feel more natural.
Optimize for change, not perfection
The goal is not to build the “perfect architecture.”
It’s to build something that can evolve.
Because requirements change.
Ideas change.
Products change.
So the real question becomes:
how easy is this to modify later?
Final thought
Good apps are not built by following patterns blindly.
They’re built by making small, thoughtful decisions over time.
And most of the time…
keeping things simple is the hardest — and most valuable — thing you can do.
Top comments (2)
When do you decide it’s time to add structure… and when to keep things simple?
I don't do mobile apps but when I'm working on projects I like to write out a layout of what problem the product is meant to solve that way I know what technologies to use, I believe this is a good addition to your post and all you've said because the wrong technologies can affect performance, scalability, cost etc. Imagine using react to build a one page static blog or Plain HTML/CSS to build a dashboard. Knowing these things help reduce some level of stress and reduces the amount of errors you might have to set fallbacks for not to talk of a more maintainable codebase