Is this a good solution for handling unique customer behavior in frontend?

Background:

We have a CMS frontend (Angular2+) that serves all clients with the same build (each tenant has their own unique URL to access their pages, mapped with URL-slugs stored in DB). Handling UI requirements can easily be implemented through modular layouts or database flags if it's generic enough, or custom CSS as a last resort.

For behavior requirements, we have until now used a no-code rule system, where we can combine Conditions and Actions that's stored in the DB and is later executed in the frontend.

However, adding very specific behavior is harder because it would generally get implemented by either:

A) Extending the current code base with more edge cases, which will be hard to maintain over time, or

B) Adding custom code for CustomerA, CustomerB, and so on, that's only loaded for the specific customer.

Option A seems wrong due to not scaling well, so I'm skipping that. Option B still adds code to maintain, but might be the best candidate.

Proposal:

Going with Option B, my plan is to setup Firebase Functions that contains the customer specific code, while making sure the functions adheres to Typescript interfaces for arguments and return values.

Example: Lets say we're calculating a price. I could then do something like:

let productData: IProductData = getProductData();
let priceResult: IPriceResult = null;
if (hasCustomPricingFn) {
    priceResult = await customPricingFirebaseFn(productData);
} else {
    priceResult = await standardPriceFn(productData);
}

This code would get called continually whenever the user makes a change, lets assume worst case is 1000 times per user session.

Pros:

• Maintainability - Each function is maintained independently, while still being kept in the same frontend repo
• Scalability - Each function can have their own isolated lifecycle, and the amount of functions has no limit
• Security - The code can't be tampered with locally
• Reduced technical debt - If a customer leaves, there's no shared legacy code in the main project

Cons:

• Relies on HTTP requests - no offline availability
• High usage quotas
• If IProductData or IPriceResult changes, N code modules needs to be fixed (compared to 1 in Option A), but at least there's Typescript interfaces that can produce errors.

Is this a good solution?

Solved it by developing a plugin architecture. The plugins are inside the front-end source code but loaded on demand.