Forking our app a lot, and it sucks. Is this new approach any good?

Question

We built an app, and fork it each time we have a new client to make a new deployment. Each deployment is slightly different as clients want customizations. This slows us down, adds maintenance cost and we want all deps to run from same codebase.To achieve this we are building a plugin system - All functionality of our system is divided into various (interdependent) plugins - Each plugin contains a set of actions (functions invoked by a service with an actor in context) along with some helper resources like input validators, access control validators etc. - These plugins are defined as a JSON schema (with proper input and return types for all functions) which is used to derive types and boilerplate code for the devs to continue writing the business logic in.Through this system, SDKs in different languages will be built that can then be used by our applicationsOur problem is that we have never seen this implemented before. Do you have any ideas, notes, on our approach. Or links on how other people solved this problem?

icedchai · Accepted Answer

At a previous company, we had a feature flag/config system where each client (tenant / org / account) had a JSON blob associated with it. The JSON turned on various features and provided any feature-specific configuration data. Some features were pretty simple and were literally just a bool. Others required a dozen lines of JSON. Clients never saw this stuff. It was done by the engineers during onboarding. It was a pretty complex B2B SaaS product and "onboarding" could take several days of back-and-forth with the client. It was also not a true plugin system, more of a monolith. The entire code base was shared across all the tenants.

epc · Answer

Either path seems like a maintenance nightmare. Are the client requested customizations primarily chrome/look & feel or functional changes to the product? Are these customizations features that could or should be merged back into the mainline product? If the underlying app or plugins change who pays for validating the changed code in re-deployments and fixing any problems caused by the updated code?

dossy · Answer

Look at techniques such as Dependency Injection, and Feature Flags. Each deployment should only be a different configuration of Feature Flags. Otherwise, you're overcomplicating things.