We have an app which is powered by APIs from a single backend. Now we wish to create a separate SaaS app for clients which will provide 80-90% of our existing product functionality.

I've been facing challenges in architecting current code base into a SaaS offering. I need help in visualizing data separation, code separation, orchestrating services, common pitfalls, etc.

Technology stack we are using is Nodejs and MongoDB.

Discussion with the tech expert at Procol

We have kept a combination of userId and clientId as composite primary key into all important collections. This helps us make query userwise, brandwise, and combination (workspace-wise).

We make use of auth token to determine which user and brand is request coming from. Accordingly, have written policies and access control.

We also suggest to make room for as many customisation as possible early on. Because SaaS is all about service and should be customisable. We pay special attention to offerings like payments and teams role management.

We haven't split-up our code base so it's a huge monolith application. However, we are now trying to split up into independent services given the scaling up issues.

We don't maintain separate database for each client (many recommend - multi tenant system). However, we have customised our existing system to run separate databases for one-two clients on their premises.

Discussion with the tech expert at Patch

If its just mongo + node, you could just separate out reusable components into a private package repository.

Then moving forward your CI/CD could take care of necessary updates to packages for SaaS and your product irrespective of which one the change was for.

However, if you foresee major diversions in both, then you are probably safer off splitting the project as long term you will most likely have two separate teams, one working on product and other on SaaS.