Building one software product is a feat of endurance. Building five at once, each with its own identity, user base, and roadmap, is a different sport entirely. When you move into the territory of multi-brand studio operations, the primary challenge isn't just writing code—it’s managing the gravity of your own infrastructure.
At a certain point, every studio founder asks the same question: Do we build every new product from scratch, or do we build a 'platform' that powers everything?
If you build from scratch every time, you waste months on the same boring plumbing—authentication, billing, transactional emails, and basic layout. If you build a rigid internal platform, you eventually find yourself fighting your own abstractions when a new product needs to do something slightly different.
Here is what we have learned about finding the middle ground.
The Gravity of the Shared Stack
In the early days of multi-brand studio operations, the instinct is to share everything. It feels efficient. You have one database cluster, one main API, and one component library. This works beautifully for the first two products. By the fifth, the weight of that shared infrastructure starts to pull back on your speed.
We’ve found that the most effective shared stacks are those that focus on the 'boring' parts of the business. These are the utilities that don't define the product’s value but are required for it to exist.
We look at sharing three specific layers:
- The Identity Layer: A single way to handle users across the studio. This allows for a 'studio account' experience where a user can move between your products seamlessly.
- The Transactional Layer: A unified approach to how we handle payments and subscriptions. We use a single logic flow for how a user upgrades or cancels, even if the price points differ between brands.
- The Deployment Pipeline: The way code gets from a developer's machine to a live URL should be identical across every brand.
By standardizing these, we ensure that when we start a new project, we aren't spending the first three weeks setting up environments. We are building the actual product.
When to Fork: The Cost of Sameness
Efficiency is a trap if it kills the soul of a product. While the plumbing should be shared, the user experience often shouldn't be. This is where many multi-brand studio operations stumble. They try to force a single design system onto five different brands to save time, resulting in a suite of products that all feel like the same gray SaaS template.
We choose to fork—or create unique instances—when the shared logic starts to require 'if' statements.
If you find yourself writing code that says if (brand === 'ProductA') { doThis() } else { doThat() }, you have a leak in your abstraction. That is the moment to fork that specific component or logic.
Forcing a shared component to handle five different edge cases makes the code brittle and hard to test. It’s often better to copy the component into the new brand’s repository and let it evolve independently. You lose the 'update once, fix everywhere' benefit, but you gain the 'change this without breaking four other businesses' safety net. In the long run, the latter is more valuable for velocity.