4

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.

Improve this question
3
  • 2
    Because this is your first kick at the can, your approach will be effective. Factoring out modules into libraries is fairly straightforward, at least compared to architecting and implementing plug-in interfaces. Especially when it comes to the branding requirements, having the top-level, outwards-facing code be specific to the industry, this will help your first implementations a lot.
    – BobDalgleish
    May 12 '14 at 22:28
  • Are you in it for money (business) or to write fantastic software (hobby)? Next comment is "The best long term solution is no good if you go bust before you get there." - which solution gets cash in you hand fastest. The hard bit - make the business and hobby interests met in a constructive way rather than tear themselves apart (and you along with it).
    – mattnz
    May 13 '14 at 4:24
  • Thanks for the comments. I'm in it for the money, no doubt about it. I think I've made my decision.
    – Jason Swett
    May 13 '14 at 13:53
2

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.

Improve this answer
6

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.

Improve this answer
1
  • 1
    Thanks for the suggestion. I asked my question because I had a hunch there were approaches I wasn't thinking about, and this is an approach I wasn't thinking about. I don't doubt that this way might be better technically, but I wonder if it also might take more of an up-front investment, which would be more of a business risk. (Could be wrong. Frequently am.)
    – Jason Swett
    May 13 '14 at 13:51

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.