What a seven-day health-check will not tell you

☷ In about a week of focused work, a useful health-check confirms system access, captures a baseline on critical user paths, and returns a ranked list of suspects: latency, memory, stability, and run-cost drivers.

☷ Exact inputs and outputs live in the statement of work.

☷ The core goal: Decide the next engineering spend with concrete evidence: Targeted fixes — A deeper Performance Surgery engagement — A structured product delivery roadmap — Or a stop decision if the system is already healthy enough.

☷ Use the checklist guide to prepare symptoms, devices, baselines, and decision-owners before Contact.

☷ A short 7-day window will not: Map every edge case in a large catalog or test every regional network condition — Simulate peak seasonal traffic spikes you have not yet experienced — Replace 24/7 continuous monitoring, full campaign load testing, or a comprehensive security audit — Invent findings from marketing screenshots when staging and analytics access are blocked.

☷ If finance needs a multi-year capacity plan, that is a different, dedicated engagement.

☷ If product wants a full redesign brief, that belongs to Delivery or Lab, not a performance readout dressed up as strategy.

☷ When leadership only needs a ranked fix list and an evidence-backed go/no-go decision on a rewrite.

☷ When the hottest user path is clearly identified and technical access is granted quickly.

☷ When the required fix is a handful of targeted code/infrastructure changes with measurable before/after metrics.

☷ When the honest answer is "this is not a performance problem" and the real need is product delivery or AI automation. Saying that early is part of the core value.

☷ Move to Performance Surgery when the readout uncovers systemic issues across multiple application surfaces.

☷ When crash or latency risks threaten a high-revenue campaign or brand reputation window.

☷ When run-cost waste and performance bottlenecks share the same root causes and require a sequenced remediation program.

☷ Surgery means: Agreed target metrics, named engineering owners, and transparent before/after reporting.

☷ A rewrite enters the conversation only when hard measurement and commercial impact support it—the health-check exists to make that call with evidence, not opinion.

☷ Name the specific user path, device, and time of day where pain shows up.

☷ Share crash reports, hosting invoices, or approximate baseline numbers if available.

☷ Name the internal stakeholder who can approve access and the next engagement.

☷ If access will take weeks to grant, tell us early so we can propose a staged plan instead of a stalled calendar.

☷ Pair this insight with the /work page when stakeholders ask whether we have shipped under campaign and catalog pressure before.

Will the health-check recommend a rewrite?

Only when measurement and risk support it. Many engagements start with targeted fixes on the hottest paths. The check is specifically designed to prevent rewrite-by-default.

Can it explain rising hosting spend?

When cloud or hosting signals are in scope and visible, yes—as ranked suspects engineering can act on. It is not a generic FinOps slide deck.

How do we start?

Send checklist notes via Contact with the health-check intent. We reply with fit, access needs, and calendar options.