A lesson from building software: A successful deployment doesn't mean your product is ready
One thing I've learned while building software is that there's a difference between successfully deploying code and knowing the application is ready for real users.
A deployment can complete without errors, the application can load, and the main features can appear to work.
But that doesn't necessarily mean everything is functioning correctly.
For example:
An API works in development but fails in production because authentication is configured differently.
A user can access their own records, but authorization rules haven't been tested to ensure they can't access someone else's.
A feature works with sample data but struggles with larger or unexpected datasets.
An update fixes one problem but unintentionally breaks a feature that was already working.
I've learned to think about deployment and verification as two separate steps.
Deployment answers: Did the new code reach the environment successfully?
Verification answers: Does the application still behave correctly, securely, and reliably in that environment?
That distinction has changed how I approach testing. I'm learning that checking whether a feature works isn't enough. You also need to test what happens when something goes wrong.
For other makers, what's one issue you've encountered after a successful deployment that changed how you test your software?
Replies
Two cases from my backend where the deploy said done and the product was not there yet. A freshly created database trigger drops events for its first minute or two: a document written 45 seconds after the deploy finished was never picked up, one written five minutes later was. And a new callable function deploys without an invoker permission, so the browser gets a 403 until that grant is added by hand. Both deploys were green. Both would have passed a smoke test that only asked whether the service answers. What fixed it for me was writing the gap down next to the deploy instructions, so the verification step is not "click around" but a list of the specific ways this stack lies: wait for the trigger, run the grant script, then create a real document and watch it move. Your authorization example is the one I would put at the top of that list, because it fails silently in the direction of working.