Production Readiness Baseline
Why this chapter matters
Frontend architecture is not ready when the happy path works locally. It is ready when the team can explain how the surface behaves under realistic devices, networks, permissions, data failures, accessibility needs, dependency failures, rollout mistakes, and operational incidents.
This chapter defines the baseline every important frontend surface should meet before the deeper architecture chapters.
Readiness dimensions
| Dimension | Baseline question |
|---|---|
| User journey | Can the critical path be completed under realistic constraints? |
| Runtime | Are expensive browser, network, and rendering costs understood? |
| Data | Are loading, stale, empty, error, pending, and conflict states explicit? |
| Accessibility | Can users complete the workflow without pointer-only or visual-only assumptions? |
| Security/privacy | Are trust boundaries, sensitive data, and third-party scripts controlled? |
| Performance | Are route and interaction budgets defined and measured? |
| Reliability | Can the surface degrade, retry, recover, or roll back? |
| Observability | Can production signals identify failure by route, device, user segment, and release? |
| Delivery | Are flags, rollout, rollback, dependency, and build risks known? |
| Ownership | Does someone own the surface after launch? |
The pre-launch review packet
For meaningful surfaces, create a short readiness packet:
| Section | Content |
|---|---|
| Scope | Route, feature, users, launch cohort, owner |
| User contract | Primary journey and recovery paths |
| Architecture sketch | Rendering, data, state, third-party scripts, dependencies |
| Failure matrix | API, network, permission, empty, partial outage, offline, third-party failure |
| Quality gates | Tests, accessibility checks, budgets, security review, manual QA |
| Observability | Metrics, logs, traces, dashboards, alerts |
| Rollout | Feature flags, cohorts, kill switches, rollback |
| Open risk | Exceptions, expiry dates, owners |
The packet should fit in a few pages. If it becomes a document no one reads, it is too heavy for Part 0 baseline work.
Failure matrix template
| Failure | User experience | Detection | Recovery | Owner |
|---|---|---|---|---|
| API timeout | ||||
| stale data | ||||
| unauthorized action | ||||
| partial outage | ||||
| slow mobile interaction | ||||
| third-party script failure | ||||
| accessibility regression | ||||
| experiment misconfiguration |
Launch gates
Use gates proportionally. A low-risk internal admin page does not need the same review as checkout, onboarding, billing, health, finance, or identity flows.
Default gates for high-risk surfaces:
- critical journey E2E passes
- component and integration tests cover risky logic
- accessibility keyboard/focus/name checks pass
- route performance budget exists
- Core Web Vitals and key interaction monitoring exist where relevant
- security/privacy review completed for scripts, storage, auth, and sensitive data
- feature flag and rollback path tested
- dashboard or alert covers primary failure modes
- owner and on-call/escalation path are named
Degradation standards
A production-ready frontend should degrade deliberately:
| Dependency fails | Expected behavior |
|---|---|
| analytics | user workflow continues; event loss is observable |
| recommendation/personalization | deterministic fallback appears |
| chart data | table or summary fallback where useful |
| export service | pending/retry state with notification or later retrieval |
| AI workflow | deterministic baseline or safe plain-text fallback |
| third-party tag | app shell and critical path remain usable |
| image/CDN | layout remains stable and content has useful alternatives |
Anti-patterns
- Calling a surface production-ready because it passed local manual testing.
- Treating observability as a post-launch task.
- Shipping feature flags without knowing which flag disables which behavior.
- Having rollback only at full deploy level when the risky behavior is a single integration.
- Documenting known risks without owner or expiry.
- Verifying accessibility only through automated checks.
- Measuring page load but not the interaction users actually care about.
Exercises
- Create a readiness packet for a critical route in your current or past product.
- Fill out the failure matrix for a route with three APIs and one third-party script.
- Define launch gates for a low-risk internal page and a high-risk checkout or billing page. Compare the difference.
- Write a rollback plan that disables one risky feature without reverting the whole release.
Source lens
This baseline pulls together Part 0 performance, browser runtime, forms, security, testing, delivery, observability, and debugging material. It prepares you for Part XII review packets and Part XI case studies.