We initially developed an eCommerce application for our client, who later requested it to be multi-tenant after most of the work was completed. We implemented the multi-tenancy feature, but the challenge arose when the client sold the application to multiple tenants, each with unique customization requirements. These unexpected individual requirements from tenants were not anticipated during the initial development.
Today, the client informed us that each tenant will have distinct and varying requirements. When we discussed this with them, they suggested maintaining separate codebases for each tenant, which raises concerns about scalability and best practices.
We are currently uncertain about the appropriate course of action. How can we efficiently implement individual requirements for each client within a scalable codebase without resorting to maintaining multiple branches?
To illustrate, consider a scenario where a column is currently a unique number, but Tenant2 wants it to be a non-unique string across the platform. How can we address such customization needs without compromising the integrity of the codebase?
A lot of this can be handled by taking a more dynamic approach to data. Creating data-driven custom fields that the customers can add to the app without necessarily having it be "code" for each field, giving them a name and data-type that can allow a lot of flexibility.
Your schema becomes more complicated because you have an arbitrary list of fields, and the processing for it becomes much more complicated because you have to key off the data-type, not the field itself. But you get a lot of flexibility.
The client's field-list can be deployed as properties files, or be part of the app's database/data-store for a truly dynamic experience.
If they truly need unique code-handling, then you are going to be in a messy situation where you will be dealing with a "main-line" trunk and each deployment will be sub-branches that you will have to merge down to and keep up-to-date, and your costs will grow rather quickly.