Launching Multiple Products from One Codebase

I have lots of ideas and not a lot of time. My latest product, TRACT, is my fourth attempt at launching a profitable side-project. I realized early on that to launch multiple ideas efficiently, I would have to make every line of code count. This post shares my approach to writing code that is structured for re-use and rapid development.

Pick a Stack

To get multiple products to market quickly, I needed to commit to a product type and tech stack. I build single-page web applications on AWS with a Springboot back-end and an Angular front-end with Github as my version control. Jumping from Spring, to Nodejs, to Django would kill my productivity and nuke my ability to reuse code. The hard part for me is finding something people will pay for; I’ll rewrite the code if and when that is my most pressing problem.

Minimize Repos

The less repos I have the better. Repositories come with overhead and I’ve found it time consuming jumping from repo to repo. In theory, the minimum number of repos required is one, but in practice I’ve found it best to use two: one for my front-end code and one for my back-end code.

So how do two repos equal four products?

Organized Code

When writing code, I first decide whether the code is a “core” service (i.e. used across most products) or a “business specific” service (i.e. unlikely to be used on another product). Core services should never mix with business specific code. Mixing the two types of code makes reuse difficult and slow thereby defeating the purpose.

An example of a core service is the front-end/back-end code for managing users. Every product I’ve launched has the concept of a user and thus needs a way for users to sign-up, sign-in, and sign-out. Writing this code for every product would be an obvious waste of time thus it’s a core service.

Intelligent Branching

Since I’ve chosen to minimize my repos, I need to utilize branching in order to leverage my organized code for reuse. I keep all core services on the master branch, which is itself a standalone product. To start building a new product, I simply branch off of master and can start writing the business logic immediately.

Pain Points

The juice is worth the squeeze, but the squeeze is by no means easy. The biggest problem I have is staying disciplined where I make modifications to core code. I should only ever make changes to core code on the master branch and then pull that code down to the product branch; however, I don’t always do this right away and that causes issues for me later.

I don’t know if it’s the nature of front-end components, or Angular itself, but I have a much harder time isolating and organizing code on the front-end than I do on the back-end.

I have a lot of branches. At a minimum, I maintain a product-master and product-develop branch, which means I’ll have ten branches for four products in one repo at all times. There can also be unavoidable merge conflicts when pulling the latest master.

The core services are never perfect. I rely on configuration files, compiler errors, and well-written generic code to minimize the overhead of launching a new product off master.

Please Ask Questions

Sitting down to write this, I realized there is actually a lot to be said about every decision I’ve made. I tried to keep it brief and keep it directional, but am happy to elaborate in the comments for anyone curious!