Insights · Checklist

The Production Checklist

A demo has to work once, for one person, on a good connection. A product has to work every day, for everyone, when something goes wrong. These are the checks we run before calling anything finished — written for founders and owners, not just engineers.

By Walid Adra · 5 October 2026

Who can see what

Most serious incidents in young products are not hacks; they are one customer seeing another customer’s data.

  1. Every record belongs to someone, and the database enforces it. If the only thing stopping customer A from reading customer B’s orders is a line of code in one screen, the next screen someone builds will forget it.
  2. Admin access needs a second factor. A password alone protects your whole business. An authenticator code costs nothing to add.
  3. Links are never the only lock. A document reachable by anyone who guesses its address is public, whatever the interface suggests.
  4. Every change to important records is logged. When a price or a balance changes, you should be able to see who changed it and when.
  5. Former staff lose access the day they leave. Make removing an account one click, and review the list every few months.

Your data

The question is not whether something will go wrong, but whether you can recover when it does.

  1. Backups run automatically, every day. Manual backups stop the week someone gets busy.
  2. A backup has been restored at least once. An untested backup is a hope. Restore one to a spare environment and time how long it takes.
  3. You know where the data physically lives. Some customers and some countries care which jurisdiction holds their records. Decide before launch, not during a sales call.
  4. Personal data has a retention rule. Keep what you need, delete the rest on a schedule, and say so in your privacy policy.
  5. Prices and money come from a fixed list, not free text. A typo in a free-text field can file a sale under the wrong product and nobody notices for a quarter.

When things fail

Something always fails eventually: a payment provider, an email service, a bad deploy.

  1. Someone is alerted when the site goes down. Customers should not be the monitoring system.
  2. Errors are collected, not just shown to users. If a checkout fails for one customer in fifty, you need to know without waiting for complaints.
  3. A failed delivery has a fallback. If your contact form’s email service is down, the message should still be stored somewhere — or handed to WhatsApp.
  4. Long tasks can resume after a crash. An import that dies at row 9,000 should restart at 9,001, not at row one.
  5. Every deploy can be rolled back in a minute. The fastest fix for a broken release is usually the previous release.

Security basics

None of these are advanced. Most products ship without half of them.

  1. Security headers are set. A content security policy, framing rules and the rest take an hour to configure and stop whole classes of attack.
  2. Secrets never live in the code. API keys belong in your host’s environment settings, and a scanner should block a commit that contains one.
  3. Uploads are checked by content, not by name. A file called photo.jpg can be anything. Check what it really is before storing it.
  4. Login attempts are limited. Lock an account after repeated failures, and limit requests per address on forms.
  5. Dependencies are kept current. Most breaches use known holes in old packages. Automate the update proposals.

Speed

Most visitors arrive on a phone, often on mobile data. Every second costs enquiries.

  1. The main page shows its content in under two seconds on a phone. Measure it with Google PageSpeed Insights on mobile settings, not on your office Wi-Fi.
  2. Images are resized and compressed automatically. A 5 MB photo straight from a camera can cost more load time than the rest of the page combined.
  3. Fonts and scripts come from your own domain. Every extra domain is another connection the browser waits for before showing anything.
  4. The page does not jump while loading. Reserve space for images and adverts so buttons stay where people are about to tap.
  5. Heavy features load only when used. A map or a chat widget at the bottom of the page shouldn’t slow down the top of it.

Handover

The real test of a build is whether it keeps running after the people who built it leave.

  1. Domains, hosting and accounts are in your name. Not the developer’s. Check this before you pay the final invoice.
  2. Setting up a new developer takes one command. If getting the project running locally takes a week of questions, the knowledge lives in one person’s head.
  3. Changes are tested automatically before they go live. Tests are what let the next developer change things without fear.
  4. There is a written list of what is not finished. A gap that is labelled costs far less than a stub that looks complete.
  5. Big decisions are written down with their reasons. Six months later, nobody remembers why. A short note saves a long argument.

If your product passes all thirty, it is in better shape than most. If it doesn’t, the rescue audit is built to find exactly which ones matter first.

Get the next one by email

One practical note at a time, when there is something worth saying. Unsubscribe in one click.

No spam. Unsubscribe anytime.