04

Production Readiness

It works when you use it. Production means it has to work when a stranger uses it, at 3am, on a bad connection, while something upstream is down — and you have to find out when it doesn't.

The gap between working and production

  • No error tracking, so failures are invisible until someone complains.
  • No backups, or backups nobody has ever restored from.
  • Secrets in the repository, or in the client bundle.
  • One environment, which is also production.
  • Nothing that tells you the site is down before your users do.

What I actually check

  1. 01

    Failure behaviour

    What happens when the database is slow, the third-party API returns a 500, or two people submit the same form at once. Prototypes usually assume none of these happen.

  2. 02

    Data safety

    Backups that exist and have been restored at least once, migrations that can be rolled back, and no path where a user can reach someone else's data.

  3. 03

    Visibility

    Error tracking, logs you can search, and an alert that reaches a human. Without these, everything else is guesswork.

  4. 04

    Deployment and rollback

    A repeatable way to ship, and a fast way to undo it. The second one matters more than teams expect.

How long it takes

The assessment is usually one to two days. What it takes to act on depends entirely on the requirements and on what the assessment finds — sometimes an afternoon, sometimes a week. You’ll see the list before committing to any of it.

Questions about this

Can you help with deployment?

Yes, and it’s one of the most common reasons people get in touch. "It works locally" is almost always an environment, configuration or build problem rather than a code problem, and those are findable.

Can you review security?

Yes, as an engineering review rather than a formal audit or certification. I look at authentication, authorization, exposed secrets, input handling, dependency risk and what your deployment leaves open. If you need a certified penetration test, I’ll tell you that instead of pretending otherwise.

Can you fix production bugs?

Yes. If something is broken for real users right now, say so when you get in touch and I’ll treat it accordingly. I’ll want access to logs and the deployment, not just the code.

Your AI-built app doesn’t need another prompt.

Sometimes it needs an engineer.

Send the messy version. That’s usually the useful version.

Show me what’s stuck.

Don’t spend another six hours fighting the same bug. Send me what you’ve got — the messy version is usually the useful version.

Both open with a short template already filled in.