The Economics of Running Five Businesses on One Technology Stack
I run five businesses. Different industries, different customers, different revenue models. And they all sit on roughly the same technology stack.
People ask me how that's possible. Or smart. The honest answer is that it wasn't a plan — it was the result of being too cheap to keep buying new tools every time we launched something. But four years in, I can see the math clearly now. And the math is interesting.
Let me walk you through what actually happens to cost structure when you stop treating each business as a standalone island.
The hidden tax nobody talks about
Most founders running multiple companies don't notice the duplication tax until it's eating them alive. You buy a CRM for business one. Then a different CRM for business two because the sales motion is different. Then an analytics tool for each. Then separate hosting, separate auth systems, separate payment processors, separate dashboards.
Each decision feels rational in isolation. The bill at the end of the quarter does not.
I ran the numbers on one of my portfolio companies last year and found we were paying for 23 SaaS subscriptions. Twenty-three. For a team of 14 people. Some tools had three active users. One had zero — we'd onboarded it during a sprint and forgot to cancel.
Here's the thing about a multi-business tech stack: the cost isn't just the subscription. It's the cognitive overhead of context-switching between tools, the integration work between them, and the engineering time spent maintaining custom glue code that does the same thing five different ways.
A shared infrastructure approach changes that equation. Not because shared tools are magically cheaper per seat (sometimes they're more expensive) but because the marginal cost of adding the sixth product line drops close to zero.
What actually gets shared (and what doesn't)
Look, not everything should be shared. I learned this the hard way. I once tried to put a rice export business and a vape e-commerce store on the same Shopify instance. The catalog structures fought each other. The fulfilment logic was incompatible. Customer service tickets got routed to the wrong team. Six weeks of work, then we ripped it out.
So here's what I actually share across businesses now:
- Identity and auth. One auth system, multi-tenant. Every internal user has one login that grants access to whatever apps they're permissioned for.
- Data warehouse. Everything flows into one place. BigQuery in my case. Each business has its own schema but the analytics layer is unified.
- Internal tooling. Admin panels, ops dashboards, alerting — built once on a framework like Retool or custom React, reused everywhere.
- Payment and finance plumbing. One Stripe parent account with sub-accounts, one accounting export pipeline, one reconciliation logic.
- Engineering team and DevOps. Same CI/CD, same monitoring stack, same on-call rotation.
What I don't share: the customer-facing product itself. Zivni, which is a field sales platform for FMCG teams, has nothing to do with how a satellite intelligence product or a premium rice export brand presents to its customers. The frontends, the brand experience, the domain logic — all separate. Trying to merge those would be insane.
Think of it as a layered cake. The bottom three layers (infrastructure, data, internal ops) are shared. The top two layers (product experience, customer-facing logic) are not.
The unit economics shift
Now the part that actually matters to anyone reading this — the money.
When I model a new business launch today, my baseline tech cost in year one is roughly 60-70% lower than it would be as a standalone startup. Not because the tools are cheaper. Because most of them already exist and are paid for.
A standalone SaaS launching from scratch might burn $180,000 in year one just on infrastructure, tooling, and the engineering hours to wire it all together. When that same product launches inside a shared stack, that number drops to somewhere around $55,000-$70,000. The remaining cost is mostly the product-specific work that can't be shared.
This matters most in two scenarios. First, when you're testing a new market and don't know if it'll work. The lower setup cost means you can kill a bad idea after six months without having wasted half a million. Second, when you're entering markets with thinner margins — agri-commodity trade, frontier-market SaaS, hardware-adjacent businesses — where you can't afford to carry standalone fixed costs.
The best route to market for FMCG products in Pakistan, for example, often requires field operations at a cost structure that wouldn't survive standalone SaaS economics. But layered on top of shared infrastructure, the operational efficiency math works.
There's also a less obvious benefit: cross-pollination. The engineer who built the routing algorithm for one business solved the same problem we hit in another six months later. The data scientist who built churn models in one product applied the same framework to a totally different domain. You can't price this in a spreadsheet but it's real.
Where it breaks
I'd be lying if I said this approach scales forever. It doesn't.
The limit is organizational, not technical. Once a business hits a certain size — somewhere around 25-30 people or $5M ARR in my experience — it starts wanting its own stack. Its own priorities. Its own roadmap that doesn't have to compete with four other businesses for engineering time. At that point, you spin it out. You hand over a clean codebase, migrate the data, and let it run.
I used to think the shared stack was a permanent architecture. Now I think it's a phase. A really valuable phase — maybe the most capital-efficient phase a multi-business operator ever has — but a phase.
The businesses I've seen fail at this don't fail because the technology was wrong. They fail because the founder treated shared infrastructure as an ideology instead of a tool. Everything got jammed into one platform because that was the rule, even when the math no longer worked.
So the real question isn't whether to share a tech stack across businesses. It's when to share, what to share, and when to let go.
I'm still figuring out that last part.