# The Hard Part of Building an Android App Isn't Writing the UI
When an Android project starts small, almost everything feels easy.
Create a screen.
Add a button.
Store some data.
Connect another screen.
Then the application grows.
Suddenly, a change that should take 10 minutes touches multiple files, breaks another flow, or creates a bug somewhere that seemed completely unrelated.
That's when I started paying more attention to **architecture**.
While working on FinLedger, I realized that building features is only one part of development.
The harder problem is deciding **where each responsibility should live**.
For example, imagine a transaction:
```text
User
↓
UI
↓
ViewModel
↓
Repository
↓
Database
That structure looks simple, but each layer has a job.
The UI should primarily care about displaying state and sending user actions.
The ViewModel should handle screen-level state and coordinate actions.
The Repository should abstract where the data comes from.
The database should be responsible for persistence.
The important part isn't following a specific architecture because a tutorial says so.
The important part is separation of responsibilities.
If the UI starts containing database logic, calculations, validation, navigation decisions, and business rules, the screen becomes difficult to reason about.
And when requirements change, everything becomes harder.
I've also learned that architecture isn't something you finish once.
As the application evolves, you discover cases you didn't consider initially.
For a lending and borrowing application, something as simple as:
"Mark this person as fully repaid."
can raise several questions.
Should the person disappear from the active list?
Should the transaction remain in history?
Can the same person be added again later?
Should a new transaction create a new record or continue the previous relationship?
What happens to existing references?
These aren't UI problems.
They're data and business-logic problems.
That's an important distinction.
A polished UI can hide bad architecture for a while.
It can't hide it forever.
My current approach is becoming:
- Define the data model first.
- Define the business rules.
- Keep UI code focused on presentation and user interaction.
- Keep persistence behind clear interfaces.
- Make state changes explicit.
- Think about edge cases before implementing the feature.
- Refactor when the architecture starts fighting the requirements.
I'm still learning this through the process of actually building software.
And that's probably the biggest lesson:
Architecture isn't about making your project look sophisticated.
It's about making the next change easier instead of harder.
#android #kotlin #jetpackcompose #softwarearchitecture #buildinpublic
Top comments (0)