I need to be able to demo our production application to prospective clients. The way I have it setup today is simple. The demo application is an exact duplicate of the production system, except that the data in the database is obfuscated to protect our current clients' data. This works great because it doesn't require any application changes.

Boss dropped a potential BOMBSHELL today and said that the demo system needs to contain a special link and that ONLY shows up on demo. He went on to explain that in the future there may be much bigger differences between the demo and production apps (e.g. an entire area of functionality). What do I do now?

Some things I have thought about doing:

  • Maintain a different branch in subversion specific to the demo system
  • Create an installation package that has the changes for demo, then revert and build a production installation package
  • Modularize the application (no idea how)
  • Say: "Screw you! I will not do it!" (LOL)
  • Use some sort of conditional logic in the app to determine if it is a demo or a production app. E.g. (if the URL contains 'demo' then show else hide).

If you haven't guessed by now, this is a web application

Anyways, I have no experience in this scenario as to which one is better or if none of these are any good. Anyone have an answer, strategy, something!?

  • Don't branch the code over this if you can help it. Don't have a separate install if you can help it. Don't put "demo" in the URL - it will make the product seem fake. You should be able to make it a config parameter. Ideally you won't have if statements checking the config throughout your code, maybe a call to see if a feature is supported, and only the object implementing that knows why - depends on your application. – psr Nov 1 '11 at 20:24
  • Maintain a different branch in subversion specific to the demo system

    • Yes! This helps truly. But be careful in how you do it. Best is when main system evolves, you should know how to bring down your changes to as close as possible.
  • Create an installation package that has the changes for demo, then revert and build a production installation package

    • This might work - but if you are doing many demos - you will loose your good part of life on this.
  • Modularize the application (no idea how)
    • This is the best answer. See below.
  • Say: "Screw you! I will not do it!" (LOL)
    • Definitely no! Not because you should be afraid. But good engineer doesn't quit challenges.
  • Use some sort of conditional logic in the app to determine if it is a demo or a production app. E.g. (if url contains 'demo' then show else hide).
    • Definitely no! This would make your product very weak over time.

When you think of a Demo product (unless you are talking about trail versions) - don't think like a 'separate product' but think of it as a 'separate environment'. If you and me both install word-press engine in our respective sites, we will have same product but different data. You must architect your product such that installation (and usage) specific stuff - can be created like how one create different content sources. Similarly, for example - you are making a native .Net or JAVA application, the functionality remains the same - but where it get's visuals (including splash screens and buttons) from can be different folders to show them in different form. Later on - the demand will come to even alter the layouts - that's when you know you need more template stuff!

Don't jump for the modularization in one-shot. As and when requirement comes, first begin a separate branch (line of development) and give the demo! (Because all demos are typically next day morning 10:30 AM). The deviation you now created tells you what modularized should have been there to be picked up from external resources. Apply that and merge it back- next time same demo would be your standard version (with different URL).

Almost always if you end up making "separate product" as a demo - you are inviting trouble or pain or both!


  • I really like your answer. For a simple hiding and showing of a link I can get away with a separate branch--like you said. – O.O Nov 1 '11 at 20:16
  • I disagree to some points of this answer. Making a different branch is not very different from making a "separate product", the thing you are (correctly) warning the OP against. A long term branch which is not merged back with the main line of development is nothing but a copy which has to be maintained separately. To avoid this, there is the well known approach of using feature toggles, which means "conditional logic in the app" and is often a much better solution than abusing SVN branches for this. – Doc Brown Sep 30 '16 at 11:14
  • @DocBrown - You haven't read the question and answer. The four options were given by OP and answer only puts out the implications. The answer does shows that quick advantage as well as pitfalls for each. while feature toggles definitely best solutions when there are several variants - svn branching is essentially an easy way out for one off such changes. It all really depends on short term vs. long term view of what these variations are likely. And as I see it, the answer does really evaluates all the options and their implications fairly neutrally! – Dipan Mehta Oct 7 '16 at 5:10
  • And frankly - what is so bad about this answer that it deserves -1 vote? – Dipan Mehta Oct 7 '16 at 5:16
  • No need to insult me. My comment is exactly about your implications. You wrote "Maintain a different branch in subversion - Yes!". My opinion here: "No, don't do this, this is very bad advice, since the demo is probably a long-term feature". And you wrote "Use some sort of conditional logic in the app - Definitely no!". But that is quite contrary to the use of feature toggles. If you have problems with the downvote, edit your question and solve these contradictions, maybe you meant things differently. – Doc Brown Oct 7 '16 at 5:48

The best approach would be to modularize so you can turn items on or off in any app.

Your demo is a prod install, with a config that turns on different things than the actual prod app and points to a different database.

  • +1 for a simple answer to a fairly simple request from his boss. – dodgy_coder Nov 2 '11 at 1:43

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.