Why Diversified Business Models Still Work — Lessons for SaaS Builders
Most Western startup advice preaches focus: do one thing, do it extraordinarily well, and resist the temptation to expand until product-market fit is undeniable. That is sound guidance — but it is not the only viable path. Japanese companies have operated under a fundamentally different philosophy for decades, and many of them are still standing, profitable, and expanding. That contrast deserves a hard look, especially for software teams and SaaS founders navigating uncertain markets.
The Conglomerate Model in Plain Terms
A Japanese keiretsu — the web of cross-holding companies built around a bank or trading house — does not look like a startup pitch deck. A single group might manufacture cars, run a logistics arm, operate insurance products, develop real estate, and sell consumer electronics. From the outside, it looks sprawling and unfocused. From the inside, it is a deliberately engineered resilience machine.
The logic is straightforward: when one market contracts, another carries the group forward. Shared relationships, supplier networks, and institutional trust become strategic assets that no single-product company can replicate quickly. Diversification is not a lack of discipline — it is a different kind of discipline, one built around continuity over decades rather than growth over quarters.
What This Has to Do With Software
Software teams may seem far removed from automotive manufacturing and real estate, but the structural lesson translates cleanly.
Platform businesses are already conglomerates. Amazon Web Services, Salesforce, and Microsoft Azure did not become dominant by doing one thing. They built a core competency — cloud infrastructure, CRM, productivity — and then systematically layered adjacent services on top. Each layer deepened customer lock-in, opened new revenue streams, and made the whole platform harder to displace. That is keiretsu logic applied to software.
Internal tooling becomes external product. Some of the most durable SaaS products started as internal tools built to solve a specific operational problem. Slack began as an internal communication tool for a game studio. Shopify's founders built their own e-commerce engine because existing options were inadequate. When a company solves a hard problem for itself and then asks "who else has this problem?", it is practicing a version of diversification — extending competency into adjacent value.
Revenue diversification reduces churn risk. A SaaS company with a single product tier and a single customer segment is one market shift away from serious trouble. Companies that layer service contracts, API access, professional services, and marketplace fees alongside their core subscription create a portfolio of revenue streams, each with a different churn profile. The aggregate is more stable than any individual line.
Three Principles Worth Borrowing
1. Build for Relationships, Not Just Transactions
Japanese business culture places enormous weight on long-term supplier and client relationships. Contracts matter less than trust built over years. In software, this maps to customer success as a genuine function rather than a retention tactic — knowing your customer's roadmap, co-designing solutions, and showing up before problems escalate. High-touch relationships have a compounding return that low-touch, self-serve models rarely achieve at mid-market and enterprise scale.
2. Treat Internal Capabilities as Transferable Assets
If your engineering team has built deep expertise in, say, real-time data pipelines for fintech compliance, that capability does not have to stay locked inside one product. It can become a consulting offering, a white-label module, or a standalone API. Japanese manufacturers routinely license manufacturing processes and supply-chain frameworks. Software teams can do the same with their hard-won technical IP.
3. Diversify Deliberately, Not Defensively
The failure mode of diversification is distraction — spreading resources across too many bets before any of them reach critical mass. The Japanese conglomerate model works because diversification happens within a coherent group identity, with shared financing and governance. For a software team, the equivalent discipline is a clear platform thesis: every new product or service should strengthen the core or open a direct adjacency. Random pivots dressed up as portfolio strategy usually destroy value.
A Quick Architecture Analogy
Think about how a well-designed microservices system mirrors this philosophy:
Core Platform
├── Auth Service ← shared asset, reused everywhere
├── Billing Service ← monetisation layer, supports multiple products
├── Notification Service ← cross-cutting concern, not owned by one team
├── Product A ← primary revenue driver
├── Product B ← adjacent offering, shares auth + billing
└── Data / Analytics API ← potential standalone product or partner integration
Each service has a clear owner but contributes to a shared platform. No single component is the entire business. That modularity is what allows the platform to absorb a change in any one area without destabilising the rest — which is exactly what the diversified conglomerate achieves at the corporate level.
The Emerging Market Angle
For software companies operating in emerging markets — across West Africa, Southeast Asia, or Latin America — the diversified model has an additional advantage: infrastructure gaps. When the ecosystem around you is still maturing, you often cannot rely on best-in-class third-party vendors for payments, identity verification, logistics, or customer support. You build it yourself. Over time, those internal capabilities become competitive moats, and eventually, products in their own right. What starts as necessity ends as differentiation.
This is a pattern Code!nk Technologies observes directly in the Ghanaian and broader West African market. Software teams here regularly build components that would be commodity services in San Francisco, and those components carry real, exportable value.
Source: "Why Japanese companies do so many different things" — davidoks.blog, via Hacker News (https://davidoks.blog/p/why-japanese-companies-do-so-many)
Why this matters for your project: Whether you are building a SaaS product, a mobile platform, or a custom enterprise system, the question worth asking is not just "what does our product do?" but "what capabilities are we accumulating?" A platform that compounds capabilities over time — even if it starts narrow — is far harder to displace than a product that stays frozen at its original scope. Design your architecture, your team structure, and your commercial model with that compounding in mind.
