What are the characteristics or features of production-quality code?

Question

This is the first time I will be delivering code for a freelance project (web-app), and, since I don't have much experience shipping code, I am having a hard time deciding whether my program is ready for deployment or not.

My understanding is that a production-level code must have the following characteristics:

• Fault tolerance: ability to survive uncaught exceptions
• Data redundancy: never lose user data
• Scalability: Handling extra load should not require re-writing the app
• Test Coverage: a "decent" amount of code tested

Some of these characteristics are specific to the program itself, while others are more environment-related (whether using multiple clusters). However, even the environment-dependent characteristics do affect the way the program is designed.

My question then is: What are the other characteristics that make production-code so different than code not meant for production?

Just to reduce the scope of the question, please focus only on web apps.

Edit: I will try to narrow down the scope by asking for characteristics specific to my situation. As a freelancer, I was responsible of everything from purchasing a VPS, to configuring it, to writing the code, to deploying it. Although the project and its setup are well documented, the customer will not be able to maintain it. The app is not complex, but depends on a lot of external components, which makes it really prone to breaking if these components change/disappear. The goal is to set up a service that would be able to last as long as possible without the customer's intervention.

Answer 1

"production-quality code" is whatever another user, who is not you, is...

1. able to use with no or minimal support. If every action is met with a bug, your software will go into the garbage
2. able to understand how to use with minimal support or documentation. If your user can't understand how to use your software, it will go into the garbage.
3. willing to use because it adds value. If your software adds enough value, maybe they'll even give you money for it. If it doesn't add enough value for you to give it away for free, your software will go into the garbage.

THAT IS IT.

Some people need absolute fault tolerance. Others don't mind as much if some data gets lost when there is a crash... assuming they see crashes very infrequently. There are no hard set qualities or requirements. And no customer cares about test coverage, what they care about is the three above points. Test coverage is a tool (one of many) you can use in order to get there, but plenty of software, some of it even good, has been built with nothing but manual testing.

Whatever software you build, the requirements are between you and your customer and if you are building software for general consumption, then pick one or few target groups and don't try to be everything to everybody. Trying to come up with some kind of generic mold seems to me rather silly.

Instead, of trying to predict or guess when your software will be production-ready, why don't you work with your customer? Give them a preview but explain that it is not production ready. Publish it on your own server and ask them to use it, poke around and give you feedback. Continue working with them until they are happy with what you gave them. In other words, they will tell you when it is production ready.