Real-World Engineering Trade-offs in Android Development

"It depends" is the honest answer to most engineering questions, but it's only useful when followed by "on what". This article names the forces behind common Android decisions so you can reason about them explicitly.

A decision framework

The forces that usually matter

• User impact: performance, reliability, UX quality.
• Team: size, skills, hiring market.
• Time and cost: to build, to maintain, infrastructure.
• Risk and reversibility: how hard to undo.
• Product horizon: prototype, growth or long-lived product.

Common Android trade-offs

Worked example: should we add a domain layer?

• Context: 6 developers, a growing app, business rules duplicated in 3 ViewModels.
• Options: (1) keep as is; (2) use cases only where logic is shared or complex; (3) mandatory domain layer.
• Forces: duplication causes bugs (user impact), the team knows the pattern, and adding use cases selectively is cheap and reversible.
• Decision: option 2, recorded in an ADR with a rule for when to add a use case.

Record decisions

# 7. Use cases only for shared or complex business logic

Status: Accepted (2026-10)
Context: Pricing rules duplicated across Cart, Checkout and Orders ViewModels; bugs from drift.
Decision: Add use cases when logic is reused by 2+ ViewModels or combines 2+ repositories.
          Simple screens call repositories directly.
Consequences: Less duplication; slight indirection; reviewers check the rule in PRs.
Revisit: If team grows past ~15 devs or we adopt KMP shared logic.

Reasoning pitfalls

In interviews

System design and senior interviews reward naming options, forces and a justified choice, plus what you'd monitor and when you'd revisit. See System Design Interview.

Frequently asked questions

Conclusion

Good engineering decisions come from clarifying goals and constraints, comparing realistic options on the forces that matter, weighting reversibility, and recording why, so the team can revisit when context changes.

Next step: apply this thinking to AI features with LLMs vs Traditional Machine Learning.