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.

  • Scalability can also refer to the ability for a system to scale in requirements. Some call it Extensibility. Maybe that deserves a point on your list. The fact is, if it can't be extended easily.. you waste time doing large re-writes just to add a feature.. and in some cases (not all).. you can't charge for that extra time. Aug 9 '13 at 2:58
  • 2
    There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
    – gnat
    Aug 9 '13 at 4:31
  • What is intended purpose of your app? Is it playing fart sounds? Is it controlling reentry of a Space Shuttle?
    – el.pescado
    Jun 22 '17 at 11:55

"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.


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.

  • 6
    Production quality code is that code which satisfies the customer's requirements, and that is it. Aug 9 '13 at 5:50
  • @RobertHarvey: that 3-point list was an attempt to give a slightly more elaborate version of "satisfies customer's requirements", clearly that wasn't a very successful attempt, but yeah... that's pretty much it
    – DXM
    Aug 9 '13 at 6:07
  • 1
    @DXM I like the idea of defining "production-readiness" with the customer. I guess my mistake was failing to do so as part of the requirements. What about elements that can't be demoed though (recovery from failure, for example)? Aug 9 '13 at 11:09
  • @verybadalloc i'd say these definitions should really be in the contract or SoW rather than requirements, but yes define what you mean as 'done' as early as possible
    – jk.
    Aug 9 '13 at 12:28
  • @verybadalloc: that one unfortunately you really should have discussed as part of the contract. Now if you ask them, "would you like full fault tolerance", the answer of course will be yes. Do the math: P=how likely your product to crash;L=when crashes how likely is it to lose data;C=how much would such data loss realistically cost? (i.e. are we talking entire DB or last 5 min of transactions? makes a difference). P x L x C = negative value in your current design. Would this negative offset all the positives you are offering? If yes, you must fix it. If you think your customer...
    – DXM
    Aug 9 '13 at 15:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.