# Headless React vs Monolithic CMS Decision Brief

Use this worksheet to record evidence, not to manufacture certainty. Complete it with product, editorial, engineering, SEO, security, finance, and operations stakeholders. Add a hybrid option when only part of the site needs a separate frontend.

## 1. Decision statement

- Decision owner:
- Contributors:
- Decision date:
- Review date:
- Current architecture:
- Trigger for change:
- Business outcome sought:
- Journeys and markets in scope:
- Explicitly out of scope:

Write the decision as one sentence:

> We are deciding whether to use __________ for __________ by __________ because __________.

## 2. Mandatory gates

Mark Pass, Fail, or Unknown. A Fail removes the option from weighted scoring until a verified mitigation changes the result.

| Mandatory requirement | Acceptance test | Headless React | Monolithic CMS | Hybrid | Evidence / owner |
|---|---|---|---|---|---|
| Critical editorial journey |  |  |  |  |  |
| Preview and scheduled publishing |  |  |  |  |  |
| Accessibility |  |  |  |  |  |
| Crawlable server or static output |  |  |  |  |  |
| Status, redirect, canonical, and locale control |  |  |  |  |  |
| Security and compliance |  |  |  |  |  |
| Data residency and retention |  |  |  |  |  |
| Availability and recovery objective |  |  |  |  |  |
| Migration rollback |  |  |  |  |  |

Unknowns are work items, not passes.

## 3. Weighted comparison

Set weights before ratings and make them total 100. Rate 1–5 only after recording evidence. Weighted points = Weight × Rating. Keep assumptions visible.

| Criterion | Weight | Headless rating | Headless evidence | Monolith rating | Monolith evidence | Hybrid rating | Hybrid evidence |
|---|---:|---:|---|---:|---|---:|---|
| Channels and locales |  |  |  |  |  |  |  |
| Experience complexity |  |  |  |  |  |  |  |
| Editorial workflow |  |  |  |  |  |  |  |
| Integration depth |  |  |  |  |  |  |  |
| Rendering and performance control |  |  |  |  |  |  |  |
| Security and compliance |  |  |  |  |  |  |  |
| Engineering capacity |  |  |  |  |  |  |  |
| Three-year operating cost |  |  |  |  |  |  |  |
| Migration and rollback risk |  |  |  |  |  |  |  |
| Vendor portability |  |  |  |  |  |  |  |
| **Total** | **100** |  |  |  |  |  |  |

## 4. Change paths

Map content and code changes separately. Name the owner, systems, cache boundaries, automated checks, manual approvals, expected delay, failure signal, and rollback for each step.

### Content change to production

| Option | Steps in order | Owner at each step | Typical delay | Failure signal | Rollback |
|---|---|---|---|---|---|
| Headless React |  |  |  |  |  |
| Monolithic CMS |  |  |  |  |  |
| Hybrid |  |  |  |  |  |

### Code change to production

| Option | Steps in order | Owner at each step | Typical delay | Failure signal | Rollback |
|---|---|---|---|---|---|
| Headless React |  |  |  |  |  |
| Monolithic CMS |  |  |  |  |  |
| Hybrid |  |  |  |  |  |

## 5. Three-year cost inventory

Use the same volume, traffic, locale, availability, and growth assumptions for every option.

| Cost area | Year 1 | Year 2 | Year 3 | Assumption / source | Owner |
|---|---:|---:|---:|---|---|
| Licenses |  |  |  |  |  |
| Hosting, CDN, and bandwidth |  |  |  |  |  |
| Implementation and migration |  |  |  |  |  |
| Frontend engineering |  |  |  |  |  |
| CMS and integration engineering |  |  |  |  |  |
| Preview and editorial workflow |  |  |  |  |  |
| Search, DAM, commerce, and other services |  |  |  |  |  |
| Upgrades and dependency maintenance |  |  |  |  |  |
| Security and compliance |  |  |  |  |  |
| Observability and incident response |  |  |  |  |  |
| Training and support |  |  |  |  |  |
| Exit or future migration |  |  |  |  |  |

Create one copy of this table per eligible option. Separate cash spend from internal team time.

## 6. One-slice prototype

Choose one representative journey that contains the hard parts: a real content type, preview, publish, localization, an integration, metadata, cache invalidation, analytics, an error case, and rollback.

- Journey:
- Content types:
- Integration boundary:
- Rendering strategy:
- Freshness requirement:
- Failure to simulate:
- Rollback test:
- Prototype timebox:
- Success measures:
- Decision-changing result:

## 7. Risk and ownership

| Risk or assumption | Likelihood | Impact | Detection | Mitigation | Named owner | Review date |
|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |

Include API authorization, content delivery failure, cache staleness, preview mismatch, plugin or dependency upgrades, migration redirects, vendor exit, skills coverage, and incident ownership where relevant.

## 8. Architecture decision record

- **Decision:**
- **Status:** Proposed / Accepted / Rejected / Superseded
- **Options considered:**
- **Mandatory-gate result:**
- **Weighted result:**
- **Prototype evidence:**
- **Why this option fits:**
- **Tradeoffs accepted:**
- **Mitigations required before launch:**
- **Owner for each mitigation:**
- **Reversal trigger:**
- **Next review date:**

## Final check

- [ ] The chosen option passes every mandatory gate.
- [ ] Ratings point to evidence, not preferences.
- [ ] Content and code release paths were tested separately.
- [ ] Three-year cost includes internal time and exit cost.
- [ ] The prototype exercised failure and rollback.
- [ ] Each material risk has a named owner.
- [ ] The decision has a review date and reversal trigger.