Submissions are open — put your project in front of the r/startupaccelerator community →
Engineering3 min read

Prototype to production: the hardening checklist

The gap between "it works on my machine" and "it can hold a paying customer" is twelve specific things. None of them take long. All of them are skipped.

The short version

  • Twelve specific checks separate a demo from something that can hold a paying customer, and they fit in a focused day.
  • Protect the data: authorize reads as well as writes, parameterize every query, keep secrets out of the bundle, decode uploads before serving them.
  • Protect the money: rate-limit anything that costs per call, make payment paths idempotent, and set a hard spend ceiling with an alert below it.
  • Keep the lights on: real error reporting, a backup you have restored from, a one-minute rollback, and a status signal.

A demo has one job: convince someone. Production has a different one: survive strangers, some of whom are hostile and most of whom are careless. The work between the two states is not glamorous, and it is unusually well-defined — which makes it the rare part of building you can simply finish.

Twelve checks between prototype and paying customers, grouped by what they protect: the data, the money, and the lights.

Protect the data

  1. Authorization on every read as well as every write. Most leaks are GETs.
  2. Parameterized queries everywhere, without exception, including the "just internal" ones.
  3. Secrets out of the repo and out of the client bundle. Rotate anything that was ever committed — history is forever.
  4. Uploads validated by decoding, not by extension. A file that claims to be a PNG should be re-encoded before you ever serve it.
  5. A deliberate answer to "what happens when a user asks for their data, or asks you to delete it".

Protect the money

Every endpoint that calls a model, sends an email, or writes to storage is a small vending machine attached to your bank account. Most founders discover this the same way: a script finds the endpoint on a Saturday, and the bill arrives before the alert does.

  1. Rate limits on anything that costs you money per call — AI endpoints above all.
  2. Idempotency on payment and submission paths, so a double-click cannot become a double-charge.
  3. A hard ceiling on spend with an alert below it. Cloud bills are the most common startup emergency that is entirely preventable.

Keep the lights on

The final group is about the hours after something goes wrong. You cannot prevent every incident, but you can decide in advance whether an incident costs you twenty minutes or a weekend — and that decision is made now, not during the outage.

  1. Errors go somewhere you will actually look, with enough context to reproduce.
  2. A backup you have restored from at least once. Untested backups are folklore.
  3. A rollback you can execute in under a minute, and have executed on purpose once.
  4. A status signal — even a page you update by hand beats silence when something breaks.

Hardening is not the opposite of shipping fast. It is what makes shipping fast survivable — the reason you can push on Friday without the weekend belonging to whoever finds the bug.

Accelerator AI

Put this article to work

Ask it a question, or turn it into a to-do list for your own project. Both answer strictly from this article — nothing invented.

Answers are generated from this article only and are a working draft, not advice.

Questions this answers

What should you check before launching a web app to real users?

Twelve things, grouped by what they protect. The data: authorization on reads as well as writes, parameterized queries, secrets out of the repo and bundle, uploads validated by decoding, and a deliberate answer to data deletion requests. The money: rate limits on paid endpoints, idempotent payment paths, and a spend ceiling with an alert. The lights: error reporting you will actually read, a tested backup, a fast rollback, and a status signal.

How do you stop a runaway cloud or AI bill?

Rate-limit every endpoint that costs money per call, and set a hard spend ceiling with an alert well below it. Any endpoint that calls a model or writes to storage is effectively a vending machine attached to your bank account, and unmetered ones are the most common preventable startup emergency.

Are untested backups worth having?

Barely. A backup you have never restored from is folklore rather than infrastructure. Restore one on purpose once, and rehearse a rollback until you can execute it in under a minute — the first incident that costs less than the rehearsal pays for it.

securityproductionchecklistbest practices
Found this useful? Send it to a founder who needs it.

Building something?

Put it in front of founders who read this — free listing, community-voted, reviewed before it goes live.

Submit your project →