Best way to scale from a technical point of view.

zig

Hi all,

I know this is probably an age old problem so even if people want to point some articles to me in this thread that I could dig into it might help.

Myself and some colleagues have produced some software based on form building/rules engine/data tracking etc mainly for manufacturing but we are finding lots of other uses for it too. We are also finding that we are building other features around the "core" selling point of the product.

We are starting to make small ground in selling it, but interest is growing especially when we put in the effort to make it known. Its Laravel PHP server side and Angular client side.

Our dream would be to simply have one piece of software and that be it but with each new potential client there are new potential problems to be resolved and requests. Sometimes people even want things that are not necessarily part of the core reason for the software but we provide them (for a cost) simply because we can and because at the moment its kind of beggars cant be choosers. E.g. someone might want it integrated with something, or someone might want 90% of what we are offering but 10% is different.

Sometimes there is such a different use for the software that we have to make large adjustments to the core code for them to be able to use it the way they wish. Some times people have different hosting requirements etc. Some even want it hosted locally on their own server.

For now we are simply creating new entire instances of our product and making the changes required.

As you can imagine this will be an absolute nightmare for maintenance if we continue in this fashion. We find that we build a new feature for a particular customer and then want to bring it across to the other ones. We are already finding ourselves copying and carefully integrating code we have written across different versions where we see it will be useful.

It will be harder to scale and every sale will have to be a bespoke sale requiring consultation of sorts.

I understand this might be as much a business problem as it is a coding one because it could be argued we are not solid on what we are offering, but as its early days its very hard to turn down opportunities where adjustments are made to get the sale over the line.

Would be interested to get your thoughts.

deconduo

Single tenant applications for multiple clients are always going to be a pain to manage. One thing that can ease the pain a bit is to try and maintain a single code base as much as possible, and then use feature flags to enable/disable functionality for different clients.

If you can have a core multi-tenant SaaS type product, and try and consolidate as many customers as possible on that it will significantly help scaling. The fewer 'unicorn customers' you need to look after the better.

smacl

Customer specific builds as you suggest are likely to be a future maintenance nightmare and I'd avoid them entirely. I get a similar demand from by own customer base on a regular basis and I either generalise the new functionality so it is available to all users or put the extra functionality in a new module that only becomes available to the specific customer. From a maintenance point of view, I add automated tests covering each customer specific module so I know that new updates don't break existing workflows. I use package called TestComplete for this, but there are plenty of options out there. From a business point of view, make sure you charge correctly for support so that maintenance becomes a profitable revenue source rather than a liability. My experience over the years is that customers have no problems paying for good support but get very pissy where the support is substandard even if it has not been paid for.

DublinWriter

The vBulletin software (the one that runs boards.ie) is really flexible when it comes to adding customised 'hooks' into the existing codebase without breaking any future releases.

It could be an interesting example for you to investigate.

Earthhorse

It's difficult to give advice without knowing what your product is or does (or at least have some specifics) but by the sounds of things you don't know what your "core" offering is. Are you doing workflow, document management, quality control?

My experience is that yes, you can build a core product and but you first need to define what this is (obviously).

DublinWriter wrote: »

The vBulletin software (the one that runs boards.ie) is really flexible when it comes to adding customised 'hooks' into the existing codebase without breaking any future releases.

And then you can add "hooks" as DublinWriter says into it. This is very difficult to do well but it will be better for you in the long run than trying to maintain separate codebases across clients (even if you are disciplined at code reuse).

So, some good Dependency Injection is an absolute must. And then you have to think carefully about which hooks should be allowed override, and which extend. And you're probably going to want unit tests in core and also make it easy for client projects to add unit tests too. And you're going to want to document how it all works so as the company grows new joiners won't have to think about the correct approach.

But the main thing is the Dependency Injection piece, IMO.

zig

Thanks for the help everyone, ive taken it all on board and mulling over it alot the last week or so and have decided it has to be one system alright. It will become a nightmare otherwise because we get feature requests off different clients for the same things and as it stands we are migrating the code across different versions.

Ive decided to take an approach of 3 options when an update is required or something is requested.

1. Make it a generalised improvement of the system itself (which means everyone benefits, this is most applicable for bugs or improvements that were needed).

2. If its a big enough feature make it its own module which we can turn on or off for clients based on what they've paid for

3. If its a very very specific exception that requires hardcoding (e.g. parsing json data or a CSV file from another piece of software) then use a hook.

It's difficult to give advice without knowing what your product is or does (or at least have some specifics) but by the sounds of things you don't know what your "core" offering is. Are you doing workflow, document management, quality control?

It is primarily a workflow and data tracking system with a very advanced form/test builder, but to be honest you are right in that we sort of stray away from that alot resulting in not truly having a core offering. This is something we are working on with a consultant.

Because as it stands it feels more like we are simply an IT company simply adding our product stamp to whatever we're doing which isn't where we want to be.

Colonel Panic

Copying code across versions? How are you distinguishing versions?

zig

Colonel Panic wrote: »

Copying code across versions? How are you distinguishing versions?

Sorry I meant instances, versions wouldnt really be a great term in this context.


Thanks all, I am now in the process of merging all the instances. Its slow and painful and sometimes I am writing new modules to cover basic features. Other times it doesnt make sense so I simply make an exception for that customer.



My next phase will be to clean up the exceptions by use of hooks/features etc.


Thanks,
Adrian

beauf

I worked in at least one place where they did every feature requested and ended up a huge buggy code base that ran out of control from them. Drowned them with bugs.

BrokenArrows

You should really focus on creating a single product rather than creating multiple customer specific versions.

We had this problem and it eventually became a disaster as any new feature or bug fix had to be replicated across multiple version and tested over multiple versions which is a huge time investment.

If a customer has a feature request then you need to evaluate it and decide if it is a good idea. If you decide it is a good idea then add it into the core product to be available for all users.
If its not a good idea then don't add it to the core product but create a separate piece of software which performs this task.

That way you have 1 single core product that you sell and then additional pieces which are available as "plugins"

This is somewhat the point of "micro services". Each service has its own function and you can install 1 or more of them to build up a whole product. If they dont want a specific feature, then dont install the service, if they want something new that doesnt fit in well with an existing service then you write a new micro service which doesnt affect any existing services.