This question is purely for learning and to step-up my technical understanding. I know there is no perfect solution and this question has possible never ending solution list but I think it's very important for every architect to understand the difference between demo and a live project.

I created many demo solutions in .Net in the past. I now have been assigned to architect and implement a production level web solution so I wanted to ask - on a very high level, what is required to convert a demo into a production level solution. From my understanding, this will require (other than functionally implementing clients' requirements):

  1. Unit testing every method
  2. Ensuring ~100% code coverage is achieved
  3. Logging all exceptions and possible pointcuts - possible with AOP
  4. Using interface design pattern, dependency injection, possibly by using a framework e.g. spring.net
  5. Using performance counters and profilers for instrumentation
  6. Applying appropriate security - i.e. windows authentication (if that's whats required by client).
  7. Transaction management on every single method
  8. Back up of the web application files before new deployment of solution

What else?

My question is more related to technical side instead of functional/documentation because otherwise we will go into another path :-)

Thank you.

  • 5
    The cynical answer would be "Your manager seeing it". Aug 25, 2011 at 10:20

7 Answers 7


I think the most important difference is that a prototype's objective is:
1. To prove that a problem can be solved in a certain way OR
2. Give client / management a feel of what the product would look and feel like

whereas the objective of a live system is:
1. To solve a certain problem / address an issue.

Notice that the objectives of the two are completely different.
Therefore, in my opinion a prototype should be thrown away before developing a live system.

This is also because a prototype is usually a 'quick and dirty' project, thrown together without any of the considerations you've rightly pointed in your question (like testing, performance, security and a lot more).
So you'd be better off starting a new, proper project, than trying to make a bad project better.

  • 2
    +1 for getting the main point through: prototypes are built to be thrown away. Trying to turn a prototype into a production release may easily doom a project right from the start. Aug 25, 2011 at 10:26
  • 1
    I think that's possible but depends on how the original prototype was developed. From a business perspective that could be an awful decision to make, depending on effort and viability of the prototype. Aug 25, 2011 at 10:27
  • @Kieren, I've been on a project where management made the "sane" decision of reusing a GUI prototype to build the production app. We suffered from that decision for years after. Due to the original decision, the app had practically no design and architecture, and it was very difficult to change that afterwards. Aug 25, 2011 at 10:42
  • 1
    I second @Kieren. Why not make the prototype a shrunk & stripped version of the prospective production app (retrospectively) -- that way you don't have to throw it away
    – treecoder
    Aug 25, 2011 at 11:29
  • 1
    I've worked at 3 different companies in the past 10 years or so, with some consulting mixed in. In that time I can not recall a single prototype that was ever discarded when the project was approved. In a corporate environment, the prototype almost always becomes the foundation of the production application. Usually mandated by upper management or at the executive level when you start putting estimates into your project plan.
    – Toby
    Aug 25, 2011 at 14:47

Not all of those things are required, depending on your requirements, or there might be way more required. If you know what I mean ;) Unit testing and code coverage are good things, but depending on how you go about other parts of the process, might not be required. Some would say that more important than performance profiling is well-documented code, or a training manual. It varies!

I realise you're looking at the technical side but hopefully you will understand my point, it varies depending on the non-technical side. Or at least, it should.

Using performance counters and profilers for instrumentation.. might be suitable, but might be massively overkill. Might not be required.

What you're missing here is failing to account for the context, scope and business requirements of the project.

By context and scope I mean - are you creating something to be used internally by a business? Customer-facing? Used by end-users? Is it in fact a jazzy version of Notepad, or a new RDBMS from scratch? What should be included will vary massively (massively!) by the project you are looking at.

By business requirements I don't mean the use-cases for the software, but the requirements of the project management / production process. If you insist you need all of those things for a production project, the cost will be reflected accordingly (very high). That could either mean it's over budget, late, or not even given the green light to start development.

It could be that more important than having a fixed set of criteria now is simply having a good production/development framework, high visibility and regular releases so quality can be assessed that way. It could be that no-one involved gives a crap about code coverage.


Interestingly, I think points 1, 2, 4 and 7 should already be done during the conception of your prototype, except that I don't think you should test every method in every class. Test the critical code, not whether get/set methods behave correctly.

Depending on the purpose of your application, where security is a big problem, point 6 may be critical enough that you need to achieve it in the prototype. Depending on the purpose of your application, where performance is the key, point 5 may be critical... You know what I mean. My opinion is that points 3, 5, and 6 may be necessary in the prototype if they are considered critical (point 8 is really valid for production applications)

Edit: it seems that my opinion differs completely from sJhonny's because I imply that I consider the prototype to be the basis/shell/skeleton of your future developments, so for me the prototype is not to be thrown away.


In addition to what has been mentioned already, in a production project you need the following (among others):

0-Choose an implementation methodology

1-Finalize and publish major requirements (including use cases, etc.)

2-Get the architecture right

3-Select the correct tools

4-Design database for performance

5-Produce your class design and workflow design

6-Determine and implement a strategy to integrate backed databases/data sources/feeds

7-Define and Implement security requirements

8-Arrange for physical implementation (Servers, connectivity, licenses etc.)

9-Plan for storage requirements and determine performance measures

10-Produce all artifacts and install in production environment


12-Deliver final solution and implement feedback


The most important feature of production quality solutions is - in my opinion - robustness.

Regardless of what happens, the solution handles the situation sensibly, notifies those needing to know, and keeps going (if the error is recoverable).

  • I agree, a system with production quality has to be able to recover from exceptions, validate data etc. A prototype normally only contains the functions you want to explain/show.
    – Kwebble
    Aug 25, 2011 at 20:41

There are two kinds of prototypes:

  • Quick-and-dirty "proof of concept" applications that get "cleaned up" and become production code. The "clean up" stage tends to either be a nightmare, or it is really a "sweep the problems under the rug" stage, resulting in massive technical debt.

  • "Mockup" prototypes or "wireframes". These can be paper-and-pencil UI sketches, or even interactive mockups done in a language where you can quickly throw this kind of stuff together without a whole lot of thought behind how it fits together. It should use fake data, no real architecture, etc. The point is that they give stakeholders an idea of what the system will be like, so that you can refine your requirements, but they CAN'T be used as part of your final solution.

I prefer the second kind. They get thrown out, because there isn't really a choice.


I say build it like a project with no demo, but now you can include what you've learned from the demo in your design. Initial coding can be bad even once you start production. You're going to have to refactor much of it anyway.

The real problem to address is your time contraint. When the decision makers want you to continue working on the demo, they're under the impression that much of the application is ready, so it won't take as long. I've heard others use this logic on why they prefer to show sketches to clients instead of overly-realistic mockups. Pay attention to the demo code because it may have discovered issues you never thought of and probably didn't document in this process. You now have to consider them (Overly simplified, but yes, the database may not be accessible for example.).

All prototypes and demos are not created equal. The entire code could be worthless or certain parts may have been done very well. It doesn't matter if it is a demo you have to know the difference. You wouldn't just throw out a legacay app and start over would you? Forget I asked.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.