I work at a development agency where we handle specialized integration projects for different clients. We have this core framework that gets reused across every single project we take on. It’s not exactly a traditional SaaS product, but it’s somewhere in the middle. Our clients basically pay for access to this base framework plus any custom features they need built on top of it.
Right now my workflow is pretty manual and messy. When a client requests a new feature that doesn’t exist in the core framework, I grab the most recent version, copy it into their project folder, build the new functionality, then manually copy those changes to other client projects that could benefit from it.
This approach works fine for getting things done quickly, but it feels really outdated. The biggest problem is I can’t keep track of which features have been deployed to which clients. I’m basically relying on my memory and looking through git commit messages across like 50 different repositories.
I tried setting up an automated sync script before that would check for updates from a main repository, but I never kept that main repo updated so it became useless pretty fast.
What’s the best way to organize this kind of shared codebase workflow? Should I be looking into private npm packages or is there a better approach for managing updates across multiple client projects?
totally agree! git submodules can really help with keeping things organized. also, how about using an internal package registry like verdaccio? itll make sharing updates a breeze and save you from all that manual work. you’ll notice a smooth workflow for sure!
Private npm packages are probably overkill here. I had a similar mess with white-label apps for different clients. Here’s what actually worked: treat your core framework as its own project with proper versioning, then lock specific versions in each client’s package.json. Stop copying features between projects manually - that’s where everything breaks. Push every new feature through the core framework first, even if just one client needs it. Yeah, you’ll deploy unused code to other clients, but handle that with environment variables and client configs. The real game changer? A simple spreadsheet tracking which framework version each client runs. Sounds dumb, but it kills all the guesswork about what features are live where. Once you can see everything clearly, then decide if monorepos or fancy tooling are worth the hassle.
Had the same problem at my last company. We switched to a monorepo and it was a game changer. We put our core framework in a shared workspace, then built each client project as separate packages in the same repo. No more headaches trying to track which features went where. The real breakthrough was adding feature flags at the framework level. Instead of copying code around for new features, we’d build them into the main framework and control who gets what through config files. Client wants a new feature? Just flip it on in their config. Done. We used Lerna to handle deployments for different clients from one codebase. The refactor took about two weeks, but we saved tons of time afterward. No more digging through commit messages or dealing with version mismatches between clients.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.