How To Review A Mobile Architecture Proposal

A mobile architecture proposal often arrives as a diagram, a folder structure or a list of patterns. That is usually too late in the conversation. Before reviewing the design, name the decision.

Are we choosing a persistence model, a navigation approach, a modularization boundary, a networking layer, a sync strategy, a design-system ownership model, or a migration path? Each decision has different risks.

If nobody can state the decision in one sentence, the review will drift. People will comment on taste, pattern preference and diagram aesthetics instead of the tradeoff that matters.

Architecture is constraint management. A proposal should say what constraint is forcing the design. Team scale, offline behavior, build time, release risk, performance, security, testability, platform consistency and migration cost are all valid constraints. They are not interchangeable.

If the constraint is team scale, the review should focus on ownership boundaries and dependency direction. If the constraint is offline behavior, the review should focus on source of truth, conflict policy and durable operations. If the constraint is performance, the review should focus on measurement and hot paths.

A proposal without constraints is just preference with formatting.

Some decisions are easy to reverse. A small view model boundary, a local helper, a feature-level folder structure. Other decisions become load-bearing: database schema, module graph, navigation framework, sync engine, design system primitives.

The review standard should change based on reversibility. For reversible choices, optimize for learning and speed. For hard-to-reverse choices, demand more evidence, a migration plan, a rollback strategy and explicit ownership.

This prevents two common failures: over-reviewing small decisions and under-reviewing decisions that will define the app for years.

A mobile review should ask questions that backend templates miss. What happens after app restart? What state is persisted? What work survives backgrounding? How are migrations handled? What happens on low storage? Does this affect launch time? What runs on the main thread? Can this be rolled out by feature flag? What metrics will prove it works?

These are not edge cases. They are the operating environment. The app will be killed. The user will lose network. The schema will change. The release will reach old devices. The proposal should be honest about that world.

Many architecture proposals describe components but not owners. That is dangerous. A module without an owner becomes a shared dumping ground. A design system without governance becomes a pile of components. A sync engine without operational ownership becomes nobody's incident.

Ask who owns the decision after merge. Who reviews changes? Who handles migrations? Who watches metrics? Who decides when exceptions are allowed? Good architecture is not only code shape. It is a maintenance agreement.

A useful architecture review should end with a small set of clear outcomes: approved, rejected, needs more evidence, or approved with conditions. The conditions should be concrete: add migration tests, measure launch time, document conflict policy, split ownership, prototype the risky path.

The worst outcome is vague approval. Everybody nods, the implementation starts, and the unresolved risk quietly becomes production cost.

Write the decision down. Future engineers should know why the system exists, what alternatives were rejected and what would make the team reconsider.