When to fracture a web application design into multiple products

Question

Have you had this problem?

You are building a complex web application for a target market, and after a while you reach a point in complexity where you can't decide if you are building more than one product.

A decision has to be made. Do you add features to turn it into a framework for multiple domains or do you resist the urge and focus just on the one product.

I'll give you a theoretical example;

You are building a web application for reviewing Movies and Television shows. Users can login and write their own reviews. After months of hard work you start to see how useful the application would be for reviewing Automobiles. All the terms/themes are for the Movie/TV industry. So you would have to refactor and take into account a multisite structure to run the web application for two different markets.

What do you call this type of problem, and how do you know when you should and should not split the project up into multiple domains.

Answer 1

Tough one. I'd resist the urge, unless you have definite demand for an automobile review site.

If that is the case: prepare the codebase to allow for different terms and themes in specific instances of the site. Much like the tag system on the stackexchange network. The tag system is shared, but the content of that system - the tag values - differ per site in the network.

Do the same for other stuff where the concept/principle should be the same, but the table content should be different on a per site basis.

Every time you get the urge to code something like if automobiles then ... else ... step back and find a different approach where the code base can stay the same for both (all?) sites and the differences are in the site's data tables and or provided by callbacks and or other means of extending the core functionality.

Resist the urge to duplicate the code base: it may seem the quickest way, but it is going to give you major headaches in the future.

Btw, I did assume you already have proper separation of visual looks (css), visual structure (html/css), and information structure/data/logic. For example by using MVC or similar design pattern.

Oh and the name for this problem: I dunno, Seeing potential? Swiss army knife syndrome? Or when you have a hammer all you see is nails? In the end whether you do or don't split the project in multiple domains is a business decision, not a programming one.