Architect Decision-Making Model

Why this chapter matters

Senior engineers often make good local decisions. Frontend architects make decisions that stay coherent across product goals, teams, runtime constraints, delivery risk, and future change.

This chapter gives you a repeatable model for moving from "what should we build?" to "what decision can the organization live with?"

The decision pipeline

Step 1: clarify the outcome

Do not start with a tool, framework, rendering mode, or component model. Start with the outcome.

Weak framing	Architect framing
Should we use microfrontends?	Which ownership and deployment constraints are making the current frontend hard to change?
Should this be SSR?	Which route outcomes depend on first paint, SEO, freshness, personalization, and hydration cost?
Should we build a design system?	Which product surfaces need consistent, accessible, evolvable UI contracts?
Should we add an AI assistant?	Which user decision or workflow improves when the UI can compose contextual guidance safely?

Step 2: identify constraints

Architects separate constraints from preferences.

Constraint type	Example questions
Product	What outcome must improve, and how will the product know?
User	Which device, network, locale, ability, and workflow constraints matter?
Runtime	What are the browser, network, rendering, and memory limits?
Data	Which data is authoritative, stale, sensitive, or expensive?
Security/privacy	Which trust boundaries and data classes are involved?
Organization	Who owns build, operation, migration, and incident response?
Delivery	What is the rollback path and migration window?
Cost	Which compute, bandwidth, vendor, and maintenance costs can grow?

Step 3: map options honestly

Every architectural decision needs at least three options:

Option	Why include it
Do nothing / defer	Forces you to justify why change is necessary now.
Minimal change	Shows the least risky improvement path.
Target architecture	Defines the durable direction if the problem is strategic.

If all options are variants of your favorite solution, you have not explored the decision space.

Step 4: score tradeoffs

Use this lightweight scoring model:

Criterion	Score 1	Score 3	Score 5
Outcome fit	unclear	partially supports	directly supports
Reversibility	hard to undo	reversible with migration	easy to undo
Runtime risk	high	known and measurable	low or bounded
Team fit	requires rare expertise	learnable	matches current strengths
Operability	blind in production	basic signals	observable and controllable
Evolution	likely to trap future work	acceptable	creates clean extension points

Scores do not make the decision for you. They force tradeoffs into the open.

Step 5: define verification

A decision is incomplete until you know how to prove it is working.

Decision type	Verification signal
rendering strategy	route budget, Web Vitals, hydration profile, server latency
state ownership	fewer cross-feature store dependencies, explicit invalidation tests
design system	adoption rate, API stability, accessibility pass rate
security control	CSP report trend, blocked sink usage, penetration test finding closure
migration	old path traffic reduction, compatibility test pass rate, defect rate
GenUI feature	eval pass rate, unsafe tool-call rate, citation coverage

Decision record template

## Context

## Outcome we need

## Constraints

## Options considered

## Decision

## Tradeoffs accepted

## Verification

## Owner and review date

Review checklist

• Is the problem framed as an outcome, not a tool preference?
• Are constraints separated from opinions?
• Are at least three options considered?
• Are reversibility and migration cost explicit?
• Is the chosen decision testable after launch?
• Is there an owner and review date?

Exercises

1. Pick a current frontend debate and rewrite it as an outcome question.
2. Score three options using the tradeoff model above.
3. Write the verification section for a decision your team already made.

Source lens

Use this model before reading Part I ADRs, Part III rendering strategy, Part IV modularity, Part VI performance budgets, Part VIII security, and Part XII review artifacts.