Seven-day performance health-check checklist

Product, platform, and operations leads whose live app or site is slow, unstable, or expensive to run. Also useful for small businesses that depend on a staff app or checkout flow and need a bounded first step before a large rewrite. If leadership is debating a full rebuild versus targeted fixes, this checklist gives you a shared language for the decision. It is not a substitute for production monitoring; it is a way to brief an external team without losing a week to vague discovery.

• —Symptoms in plain language: What users or staff see: lag on checkout, crashes after long shifts, battery drain, timeouts at peak. Include when it started and how often it happens.
• —Access you can grant: Staging or production read access, analytics, crash reports, hosting console, or device samples. Note what you cannot share yet.
• —Current baseline: Any numbers you already have: page load, API latency, crash rate, monthly hosting bill. Approximate ranges are fine.
• —Real devices and networks: Phones, tablets, or browsers your customers and staff actually use, plus typical network conditions in your market.
• —Cost pressure: Whether finance is asking about rising cloud or hosting spend, and which workloads grew recently.
• —Business risk window: Upcoming campaigns, launches, or seasons where failure would hurt revenue or reputation.
• —Decision owner: Who can approve access, scope, and the next engagement after the readout.
• —Success for this check: What a useful outcome looks like for you: a ranked fix list, a go/no-go on rewrite, or a clear run-cost story for leadership.

We confirm access and success criteria, capture a baseline on the paths that matter (checkout, staff flows, peak hours), then return a ranked list of suspects: latency, memory, stability, and likely run-cost drivers when those signals are visible. Exact inputs and outputs are confirmed in the statement of work. This is a decision tool, not a promise of fixed percentage gains. Expect questions about real devices, peak windows, and which metrics leadership already trusts. If access is delayed, the calendar slides; we do not invent findings from marketing screenshots alone. When cloud cost is in scope, we look for wasteful patterns that engineering can change, not a generic FinOps slide deck.

If the findings justify it, work continues under Performance Surgery with agreed targets and before/after metrics. If the system is healthy enough, we say so. If the real need is product delivery or AI automation, we point you there instead of forcing a performance engagement. Keep the checklist notes; they become the first appendix of any follow-on statement of work and reduce re-briefing when a new stakeholder joins mid-project.

Use it when a live surface is already in market and something measurable is wrong: conversion dips at peak, staff apps crash after long shifts, or hosting spend climbed without a matching traffic story. Skip it if you only need a brand redesign, a greenfield MVP with no production traffic yet, or a compliance audit that is not about speed and stability. Haikotek’s Performance Surgery page describes the deeper fix program; this guide is the briefing layer that makes that program honest. Pair it with the Work page when you want proof that we have shipped under catalog and campaign pressure before.

A ranked list of suspected performance or stability issues tied to observable behaviour.

Where in scope, ranked suspects for wasteful cloud or hosting usage that engineering can act on.

A recommended next step: targeted fixes under Performance Surgery, a delivery roadmap, or a different path if the bottleneck is not technical.

Asking for “make it faster” without naming the user path, device, or time of day where pain shows up.

Withholding staging or analytics access until after a proposal, then expecting a precise price and timeline.

Treating a health-check as a free rewrite plan. The output is ranked suspects and a recommended next step, not a full redesign.

Ignoring run-cost signals when finance is already asking about hosting growth. Performance and spend often share the same root causes.

Is seven days a hard SLA?

It is the usual shape for a bounded assessment. Calendar and access constraints can change the window. We confirm timing in writing before work starts. If your team cannot grant access within a few days, say so early so we can propose a staged plan instead of a stalled week.

Do we need a full rewrite?

Often no. Many engagements start with targeted fixes on the hottest paths. A rewrite is only recommended when measurement, risk, and commercial impact support it. The health-check exists to make that call with evidence, not opinion.

How do we start?

Send the checklist notes via Contact with the health-check intent. We reply with fit, access needs, and calendar options. If you already have crash reports or hosting invoices, attach or summarise them; that shortens the first reply cycle.