Productizing your Website

Igor Royzis

So you’ve built your website, launched it and are now adding new features and slowly enhancing the site. Suddenly, you get contacted by one of your users. He says that he loves the site. He has a business idea for a different site in a different industry and he feels that your site has more than 80% of the functionality required by his “idea”. He wants you to customize your site for his needs for a nice chunk of change.

Sounds good, right?

You quickly agree. It feels great that by building your own site you also created something that others would want to use with minimal customizations. You discuss the requirements, create a proposal and get the ball rolling.

There are two ways to approach this:

(1) Create a copy of your source repository and customize that “copy” for your new customer.

PROS: Easiest and fastest in terms of effort and duration
CONS: You need to maintain multiple source repositories. Changes to common code have to be applied and regression tested multiple times. Creating custom solution for customer #3, #4, etc may make the environment unmanageable in terms of resources.

(2) Refactor your original platform to be as generic as possible, but don’t go overboard. For example, make your services and database functionality generic, but create custom web pages. Make your platform a core foundation for the new platform. All the common code (say 80%) will stay in the same code repository and customer-specific code will have it’s own source branch.

PROS: Most back-end functionality, services and some UI controllers code will be managed in a single source repository. Bugs and enhancements will be applied and tested in a single location.
CONS: This will take more upfront effort to refactor the existing code.

I obviously suggest the second approach. It doesn’t have to be a daunting task to refactor existing platform. As a matter of fact, if original platform is designed intelligently, refactoring should be minimal. Following design concepts will assure minimal refactoring when the time comes to “productize” your website:

Do not hard-code any configuration variables. Use a simple database table or platform-specific property files.
Make your main navigation (menus) database driven.
Make all the static information which is presented in the form of lists or drop-downs database driven.
Include minimal amount of business logic (if any) in your dynamic web pages (php, jsp, etc). Try to push most of the business logic into services.
Don’t bundle all service logic into giant classes. Create a separate service manager for distinct groups of business logic (company, user, project, mail, etc).
Design your database model using more generic terminology. For example, instead of having a table called “company” to represent company information (e.g. name, address, website, contact person, etc), call it “group” to allow for companies, divisions, departments, teams, etc to use this table.
In terms of infrastructure, make sure you can deploy your website on various operating systems (linux, windows, mac os) and be able to use various databases (mysql, oracle, ms sql server, postgresql, etc). This all can be achieved by using platform neutral technologies.

You’ll be surprised of how many new ideas you personally can come up with on utilizing the code you’ve built, especially if you designed it well.

Happy coding!