Forking an application for an “enterprise” customer

Question

Note: this is mostly a technical question but I have to explain the business background first.

THE BUSINESS PART

I have a really interesting situation on my hands, at least interesting for me.

For the last 3.5 years I've been building a business/application called Snip Salon Software. It's scheduling software for hair salons. Significantly, I've specifically targeted hair salons as opposed to nail salons or tanning salons, which have different needs.

The business has experienced a certain level of success but nothing spectacular so far. I have 6 salons in my local area using the product.

Some time ago I was approached by a couple of entrepreneurs in the lash salon industry, which has different scheduling needs from hair salons. (The beauty industry is a surprisingly complex space!) These guys would basically like me to white-label my product for them so they can sell it as part of a "business in a box" type package they offer to start-up lash technicians.

THE TECHNICAL PART

So the challenge I'm faced with is:

• I don't want to have one application that serves both hair salons and lash salons. I think it would quickly turn into a nightmare.
• I don't want to have applications running mostly the same code. That would be silly.

And it's not just the features - all the branding, etc. will almost certainly be different for each version.

So what I think I want to do is first fork the codebase and set up separate hosting, etc. for the lash salon application. Then, over time, maybe I want to factor out the common parts (e.g. appointment reminder emails) into modules (I'm using Ruby on Rails, so I'm talking Rails engines) and then let each fork of my application use the same copy of each module. I would of course situate it so that each engine only contained functionality that was common to the two forks of the application.

My question: from a technical perspective, how would you handle this situation?

Feel free to chime in on the business side, too.

Answer 1

From a business perspective, I think you're right to go with the simplest possible method of splitting the codebase and then gradually working on rejoining them. While it might sound best, from a technical perspective, to rearchitect and rewrite your core application, it doesn't make sense to put in all that work up front unless you're absolutely certain that the lash project will be a profitable long-term business relationship - for all you know, they could flake out on you & be gone in 6 months.

Answer 2

I would have gone the other way - instead of making the common parts a reusable library, you should implement a plugins architecture and create plugins for the different types of saloons.

You'll have the main application code, which includes the common codebase and some infrastructure for the plugins(e.g. interfaces to be implemented in the plugins), and the plugins themselves will be different projects. You should also make it possible to create bundles of the application+specific plugins, so lash saloon guys can have a lash saloon bundle that'll be easy for their customers to install.

The main advantage of the plugins architecture over the shared modules architecture is that the main application needs to have a lot of boilerplate code for orchestrating the different modules\plugins. In the shared modules architecture you'll have to replicate that boilerplate code in each fork, but with the plugins architecture you only need it once, in the main application.