How a Monorepo Architecture Cut Our Client's Deployable Codebase and Scaled Their Multi-Tenant E-Commerce Platform

Background

Our client runs a multi-tenant e-commerce builder built on Vue.js and Laravel. Every business that signs up for their SaaS gets its own tenant, spun up on a dedicated AWS EC2 instance. It's a solid model, until the codebase starts growing.

As the platform added new themes and components, the shared codebase kept expanding, and every tenant's instance was pulling in the entire thing, whether it needed most of it or not. Deploying the full codebase to every single tenant was starting to look a lot like renting a separate house for every guest at a party. It worked, but it wasn't sustainable, and it was getting more expensive with every new tenant onboarded.

The challenge

The team came to us with a platform that was starting to strain under its own growth. Three problems stood out:

1. A codebase that kept ballooning. Every new theme or component added more weight to an already large shared codebase.
2. Expensive, redundant deployments. Spinning up a full copy of the codebase on each tenant's EC2 instance was burning through infrastructure budget for functionality most tenants weren't even using.
3. A scalability ceiling. The architecture needed to support hundreds, eventually thousands, of components and themes, without deployments getting slower or heavier as it grew.

Our approach

We restructured the platform around a monorepo, so every component and theme lived in one well organized, central repository instead of being tangled into a single monolithic build. Alongside that, we set up a private npm registry to package components as installable, standalone packages.

That combination meant we could pick exactly which components a given tenant needed and install only those, instead of shipping the entire codebase to every instance. With the UI components pulled out into their own packaged, distributable pieces, the core application itself could shrink down to a lean micro-kernel, responsible only for the fundamental operations needed to run an e-commerce store, with everything else loaded in on demand.

How we built it

Managing the monorepo with Lerna

We used Lerna to manage the monorepo and streamline the npm publishing workflow across all the packages. Based on the theme and components a tenant selected, our automated deployment process updated that tenant's package.json to include only the relevant packages, then pulled them in from the private npm registry.

Dynamic components in Vue.js

To make component loading flexible on the front end, we leaned on Vue.js's dynamic component feature, which let the platform render whatever component a theme or user selection called for.

That gave the platform the flexibility to mix and match themes and components per tenant without hardcoding every possible combination into the build.

Results

• A leaner, more targeted codebase. Selective component installation meant each tenant's deployment only included what it actually needed, cutting the deployable codebase down significantly.
• Lower infrastructure costs. Removing redundant, full codebase deployments across tenants brought a real reduction in resource usage and infrastructure spend.
• Room to grow. The architecture is now built to take on new themes and components without the performance hit or deployment overhead that used to come with scaling up.

Conclusion

This wasn't a quick patch, it was a structural change that gives the platform real room to grow. The client's team can now add new themes and components at a much faster pace, without every tenant's deployment growing heavier in the process. It's a good example of how the right architecture decision, made early, can turn a scaling problem into a non issue.