Client Cms
Client CMS Contender Evaluation & Mobile BAU Requirements
1. Evaluation Context & Requirements
For SiteSwarm to scale across local businesses without daytime engineering interruptions, business owners must be able to self-serve routine Business-As-Usual (BAU) updates—such as holiday hours, emergency closures, and daily specials—directly from their smartphones.
Core Evaluation Criteria:
- The 60-Second Mobile Benchmark: A non-technical business owner must be able to open the administrative interface on a smartphone and publish an operational update in under 60 seconds.
- The Zero-Lockout Mandate: Core operational updates (hours, announcements, daily specials, contact info) must be available out of the box without requiring an engineer or triggering a Git/CI rebuild.
- Layout & Input Safety: Content data must be strictly separated from presentation layout (plain-text length caps, HTML stripping, and pre-verified semantic alert styles) so client edits cannot break mobile responsiveness, inject scripts, or violate accessibility contrast.
2. CMS Contender Evaluation Matrix
| Evaluation Criteria | Monolithic Node CMS (Strapi / Directus) | Payload CMS v3 (Next.js / OpenNext) | Git-Backed SPA (Decap / Tina / Keystatic) | EmDash CMS (emdash on Astro + Workers) |
|---|---|---|---|---|
| Edge Worker Native? | No (Requires persistent Node server) | Partial (Heavy bundle via OpenNext) | Yes (Client SPA) | Yes (Native Astro + Cloudflare Workers) |
| Live Propagation Delay | < 1s | < 1s | 60s – 180s (Requires CI/CD rebuild) | < 2s (D1 write + Cache-Tag purge) |
| Mobile Usability | Desktop-heavy UI | Sluggish cold starts on mobile | Fragile GitHub OAuth on mobile | Responsive Astro/React Studio |
| Maintenance Footprint | High (VPS / containers) | Moderate | Low | Zero server upkeep (Serverless D1 + R2) |
| Evaluation Verdict | Rejected | Specialized Enterprise Only | Rejected for Real-Time BAU | Selected Platform Standard |
3. Where Architectural Outcomes Are Documented
The architectural outcomes resulting from this evaluation are captured in their respective domain specifications rather than duplicated here:
- App-Hosted Capability Model: Provisioning the CMS as an
app-hostedcapability is defined inCAPABILITY_MANAGEMENT.md. - Worker Isolation: Offloading the CMS studio and database bindings into a backing service worker is defined in
MULTI_WORKER_PLATFORM_SERVICES.md. - Edge Caching & Sub-2s Invalidation:
Cache-Tageviction on publish is defined inAPP_SERVING_CACHE.md. - Media Uploads: R2 master storage and Cloudflare Images transformation are defined in
IMAGE_AND_MEDIA_MANAGEMENT.md.