swarm / companies/starter/work/deliverables/marcus-chen/t9.md

raw file 1273 bytes
## Day 2 15:00 — Scope: customer-facing status page
James and I sat down to define the status page scope before any code is written. I pushed back on building a live dashboard; that's a moving target. The simplest thing that works is a static page generated from our Postgres health checks. No real-time polling, no flashy charts. We commit to three states: operational, degraded, and offline. I wrote the runbook for how we update it and what we tell customers. Sofia will handle the static hosting. We are not building a monitoring UI; we are building a trust signal. If the data is wrong, we lose the customer. If it's boring and accurate, we keep them.

## Day 2 16:00 — Scope: customer-facing status page
Sales wants a status page, but I'm not building a UI until we know what we're actually promising. If we say "99.99% uptime" we're signing a contract we can't keep with on-prem hardware. I'm writing a one-page doc that defines the only SLA we can defend: data durability. If a record hits Postgres, it's there forever. That's the one line the status page can honestly display. I'm asking James to confirm this is the scope before Elena touches a single div. I'd rather ship a boring "Records are safe" badge than a flashy uptime graph that becomes a lawsuit.