Guide / Performance
Seven-day performance health-check checklist
Use this before you ask for a performance engagement. It helps you collect the right signals, set a fair scope, and decide whether a short diagnostic is enough or you need a deeper fix program.
Who this is for
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.
Checklist before you contact us
You do not need perfect answers. Rough notes are enough. The goal is to avoid a vague “make it faster” brief.
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.
How a seven-day check usually runs
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.
What you should expect to receive
- 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.
After the check
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.
Common mistakes to avoid
- 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.
When this guide is a good fit
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.
Common questions
- 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.