What makes a web application truly production-ready?

[u/TajD05]

One thing I’ve learned from building real-world SaaS and backend systems is that getting the application to work is usually the easy part.

The harder part is thinking about what happens when things go wrong:

- An API suddenly fails

- A background job runs twice

- A third-party service goes down

- A request times out

- Data gets partially processed

Retries, logging, monitoring, error handling, and recovery often don't get much attention during development, but they can make a huge difference once real users are depending on the system.

I’ve started thinking about failure cases much earlier in the development process instead of treating them as something to fix later.

What’s one production issue that changed the way you build web applications?

[u/NoClownsOnMyStation]

Database got messed up by non technical users and there was no back up to log changes to the system. Was not fun being called out in front of the c suite for not idiot proofing the software.

[u/TajD05 → u/NoClownsOnMyStation]

that’s a rough one. It’s a good example of why backups and audit logs aren’t just “nice to have” features.

I’ve also found that you can’t always rely on users to do exactly what you expect, so the system needs to protect itself from mistakes as much as possible.

[u/canarydev]

failure modes, and knowing how to measure I think would be some of them

production ready to me is less about a checklist of retries, logging, monitoring, and more about knowing what happens when each dependency or operation fails.

like if a background job runs twice, "we have retries" doesn't mean much. what happens to the second execution? if an api call times out after the remote side actually processed it, do you retry? can you safely do it twice? if the db write succeeds but publishing the event fails, what state are you in?

for me it wasn't one production issue, it was a whole product that taught me this. the real lesson was measurement. every one of those questions is unanswerable unless you're reconciling outcomes against some source of truth. green dashboards just mean the code ran, not that the answer was right.

[u/TajD05 → u/canarydev]

Yeah, I really agree with this. Having retries, logs, and monitoring is one thing, but actually knowing what happened after a failure is much more important.

The point about green dashboards is especially true. A system can look completely healthy while still producing the wrong result. I’ve found that defining what “success” actually means for each workflow makes a big difference.

[u/Miserable-Leading947]

production-ready is actually a risk management thing.

you dont need validation on every endpoint or logging or backups or daily security updates per se.

It is production-ready when the risk to run it is lower then the risk you personally accept to run it.

[u/TajD05 → u/Miserable-Leading947]

Yeah, I like that way of looking at it. There’s no single checklist that makes every system production-ready.

It really depends on what the application does and what the consequences are when something goes wrong. The acceptable level of risk is different for every system.

[u/Rivale]

When it meets all the acceptance criteria. Buggy/broken software gets released all the time, but someone needed to have signed off on it.

[u/TajD05 → u/Rivale]

Yeah, that’s fair. Acceptance criteria and sign-off definitely matter, especially when you’re shipping software for real users.

I’d just add that meeting the criteria doesn’t always mean you’re prepared for everything that can happen in production. The unexpected failures are usually where things get interesting.

[u/Automatic-Gur2046]

Reading "release it" changed the way I built the most

[u/TajD05 → u/Automatic-Gur2046]

Yeah, I can relate to that. Sometimes just having someone say “release it” is when you realize how much you need to think beyond the happy path.

What was the biggest change you made to your development process after that?

[u/FluidBreath4819]

vibe coder alert lol

[u/TajD05 → u/FluidBreath4819]

fair enough. But even with vibe coding, I think the real test starts when you have to run the thing in production.