A simple checklist for shipping fast web apps

Shipping fast is rarely about working faster. It is about not redoing things, not debugging things you could have prevented, and not discovering problems in production that a boring habit would have caught in week one. Over time I have collected the habits that actually move the needle, and they are all unglamorous.

Before the first line of code

• Write down the goal and the measure of success in one sentence. If you cannot, you are not ready to build.
• Pick a boring, proven stack you already know cold. Novelty is a delivery tax.
• Set up linting, formatting, and types on day one — retrofitting them later never happens.
• Ship a live preview with the first commit. A URL that updates on every push changes how everyone reviews the work.

While you build

• Components over copy-paste. When you paste the same markup a third time, extract it.
• Keep the bundle honest: self-host fonts, compress images, and treat a new dependency like a new employee — it needs a reason to be there.
• Security as a default: no secrets in the repo, validation at the boundary, security headers from the first deploy.
• Accessibility as you go — keyboard, contrast, screen reader — because fixing it at the end means rebuilding the end.

A fast app is the side effect of boring infrastructure and disciplined habits, not heroic effort in the final week.

Before you ship

• Test on real devices and real networks, not just the fastest laptop in the room.
• Measure: page weight, time to first byte, and one pass of Lighthouse. Write the numbers down; compare next time.
• Click every error state: the empty page, the failed request, the 404, the validation message. Errors are part of the design.
• Write the deployment runbook while you still remember how the deploy works.

After launch

• Monitor uptime, errors, and real usage from day one — a launch nobody watches is a launch nobody knows failed.
• Keep a change log and make the next deploy as boring as this one.
• Schedule the follow-up: revisit the goal you wrote in week one and check whether the measure moved.

The point

None of this is clever. That is the point. The teams that ship quickly are not the ones with the smartest architecture — they are the ones whose habits remove the rework. Setup checks, build checks, ship checks, post-launch checks. The checklist is the strategy.