People occasionally look at my work and ask a reasonable question: why build several digital businesses instead of concentrating everything into one company?
From the outside, the businesses do not look particularly similar. One helps people start ecommerce businesses. Another sells website design directions. A third develops focused software. A fourth works on a specialist redevelopment platform. I also explore niche marketplaces. That is a genuine breadth of activity, not four names for the same product.
The answer is not that running multiple businesses is automatically smarter. It is that I keep finding different customer problems that can be approached with a related set of skills: research, design, software, ecommerce operations and increasingly AI-assisted development. The opportunity is real. So is the danger of spreading my attention too thin.
First, a solo founder is not the same as a one-business founder
A solo founder is someone who starts a venture without a co-founder. It does not necessarily mean doing every task personally, employing nobody or operating exactly one business. Those distinctions matter because conversations about entrepreneurship often confuse ownership, team structure and business focus.
My public portfolio describes four companies—EcomChief, Depiction Studio, Rudh Systems and NIR.Systems—alongside a group of marketplace projects. Those are separate customer propositions, with different buyers, workflows and responsibilities. I do not regard the number of brand names as an achievement by itself. The better question is whether each one solves a clear problem and deserves the ongoing work it creates.
What the four businesses actually do
EcomChief is about reducing the setup friction of starting an online business. Its offering includes ready-made ecommerce stores, affiliate sites, agency websites and digital business assets. The useful outcome for a buyer is a starting point they can take ownership of; it is not a promise of customers, revenue or automatic success.
Depiction Studio approaches a different moment in the process. A business owner may already know what they want to sell but struggle to imagine the website. The studio lets people explore fully developed design directions before deciding whether to own a design or have it adapted and built. Here the product is clarity about design and implementation, not a ready-made ecommerce operating model.
NIR.Systems addresses recurring operational jobs: producing quotes, documenting field work and shaping software around a specialist industry. It is closer to the daily mechanics of a business. A working form, reliable records and understandable output matter more than a long feature list.
Rudh Systems is much more specialised. Its public product focuses on housing-society redevelopment, with document access, project stages and information for different participants. Its public demonstrations use sample data; they should not be confused with claims about private member records or results at a particular society.
What connects these businesses is not their target market. It is the process of turning a confusing task into a more usable digital product. That connection gives me a reason to explore adjacent opportunities. It does not excuse me from proving that each separate offer works.
Why I do not simply fold everything into one brand
There is a good argument for building one company: concentrate attention, strengthen a single reputation and give customers one clear message. I take that argument seriously.
But imagine a potential customer trying to compare a ready-made Shopify store with a housing-society redevelopment portal and an industry-specific quoting tool on the same sales page. The audiences, buying decisions, support expectations and trust signals are different. Putting everything beneath one broad company label could create more confusion than efficiency.
Separate brands can give separate promises. The person buying a website design should not have to decode a software subscription. A housing-society committee should not have to navigate a storefront catalogue to understand its portal. The division only earns its keep if it makes those journeys easier.
That is the strongest case I can make for several businesses: separation at the customer-facing level, with sensible reuse of skills and systems behind the scenes. It is a design and operating decision, not a claim that a portfolio always outperforms a focused company.
The advantage I look for is shared capability, not random diversification
Digital businesses can look unrelated while relying on similar underlying work. I explore the software side of that process in my piece on building working software with AI. Someone still has to find a genuine problem, define the offer, design the interface, structure information, implement the product, write accurate copy, test the important paths and support the people using it.
Those are capabilities I can carry between projects. A lesson about clear onboarding in an ecommerce purchase can improve the way a design buyer understands a handover. A lesson about deterministic pricing in specialist software can sharpen the way another business explains what a system does and does not automate.
There are limits to that reuse. A polished website layout can travel across industries; a legal obligation, customer permission boundary or pricing rule usually cannot. Rudh's redevelopment information needs a different level of privacy and domain review from a public design catalogue. Copying a pattern without its context would be a mistake.
The distinction I return to is simple: reuse methods, not assumptions. Having several ventures is only an advantage when useful learning transfers without making each customer experience generic.
The risk nobody should romanticise: divided attention
Running several businesses multiplies the number of things that can interrupt the day. A payment integration changes. A customer needs help. A product description becomes inaccurate. A software dependency needs attention. A marketplace needs better supply and demand, not another redesigned landing page.
It is easy to mistake activity for progress when there are many dashboards to open. Launching a new brand can feel productive precisely because the difficult part—distribution, retention and customer service—has not arrived yet.
I also do not assume that several brands automatically diversify risk. If they depend on the same founder, marketing skill, technical services or limited pool of attention, their operating risks may be correlated. Four websites do not create four independent management teams.
This is where focus advocates have a point. Context switching has a cost, and every additional venture adds commitments. The practical question is not whether I can create another website. It is whether I can maintain the promises already made.
One useful framework: what does each business contribute?
A multibusiness portfolio should be evaluated by how the parts are managed, not merely by which businesses appear on the list. Harvard Business Review makes that distinction in its September–October 2024 analysis of multibusiness strategy. That work examines corporations, not solo founders, so I treat it as a useful management principle rather than proof that my own approach will succeed.
For my scale, I would translate the principle into a small set of questions. Does the venture serve a distinct customer? Is the offer easy to explain? Can the core journey be demonstrated? What recurring service, maintenance or sales effort does it require? What capability, if any, becomes more useful because of the other ventures?
If the answer to the last question is only 'the logo exists and I own the domain', that is not strategic value. An idea has to earn attention through some combination of genuine demand, clear product quality, learning, revenue potential and manageable cost. Those are evaluation criteria, not published measurements of my companies.
How I would separate active businesses from interesting ideas
One discipline I consider important is making a hard distinction between an operating business, a live product still finding its market, and a concept worth exploring later. They are not the same stage, and they should not consume the same amount of time.
An operating business has customers or ongoing responsibilities that need continuity. A live experiment has a specific hypothesis to test, such as whether buyers understand the offer or complete its intended task. An idea on the shelf has no reason to demand daily attention.
This is also how I think about the marketplace projects in the portfolio. A marketplace is not successful just because listings, filters and payment screens exist. It needs a genuine reason for both sides to return. Until that is demonstrated, the honest description is a marketplace project or experiment—not an established network with proven transaction volume.
My default advice to another solo founder would be to set a small evidence threshold before expanding the number of active projects. Could a real customer complete the task? Is there an identifiable route to acquiring that customer? Is the ongoing support burden understood? If not, improving the existing offer is probably a better use of the next week than launching a new brand.
A decision matrix for one business or several
| Situation | Better next move |
|---|---|
| One offer still unproven | Focus on its customer journey and demand before launching another |
| Existing customers, fragile operations | Stabilise delivery and support before diversifying |
| Distinct audience, transferable capability | Run a time-bounded test with a clear evidence threshold |
| Unclear compliance, support or domain expertise | Acquire capability or decline the opportunity |
If one offer still has an unclear audience or unreliable delivery, the priority is to make that business work before adding another. If the current offer has a stable customer journey but requires continual founder intervention, improve its operating system before diversifying.
If a second opportunity serves a genuinely different buyer, has a clear problem and uses capabilities you already possess, a bounded test may be reasonable. If its only advantage is that the name and domain are available, leave it as an idea.
If the new business would require expertise, support coverage, compliance or a sales process you cannot credibly maintain, either find the right capability or decline the opportunity. The discipline is not saying yes to every possible business. It is being able to explain why this one deserves to exist.
Why the customer should never feel the founder's complexity
Behind the scenes, I may think about several products and markets. From a customer's point of view, none of that matters. They want a clear answer to a specific question: what will this product help me do, what will I receive, and what happens if something goes wrong?
A ready-made store buyer needs clarity on ownership, the handover and the work required after launch. A design buyer needs clarity on licence, files and customisation. A software user needs to know which data is saved and what the service actually supports. A redevelopment committee needs clarity about documents, roles and access.
Good separation protects those differences. It also makes accountability more visible. A customer should not have to understand a founder's entire portfolio to know which business is responsible for their purchase or support request.
What I would change as the portfolio grows
The next improvement is not necessarily another launch. I would rather reduce duplicated work, make ownership of decisions clearer, retire weak assumptions and protect more time for the businesses with genuine demand.
That means resisting the temptation to keep polishing the front end while avoiding the harder questions. Do the customer journeys work? Are the instructions accurate? Are costs and responsibilities visible? Is a project earning the time it receives?
It also means being willing to stop an idea. A sensible portfolio is not a museum of every domain a founder ever registered. The best decision might be to pause an experiment, simplify an offer or concentrate on one thing for a while.
So, would I recommend multiple businesses to a solo founder?
Not as a starting prescription. I would recommend learning to solve one real customer problem first. Prove that someone values it, understand delivery and maintenance, and get comfortable with the unglamorous work after launch.
I run several different digital businesses because the problems are distinct, while the skills used to research, design and build solutions often overlap. That is a coherent reason to explore more than one. It is not a promise that each venture will become successful or that more ventures automatically mean less risk.
The standard I want to be judged by is not the number of brands in my portfolio. It is whether each customer gets a useful, honest and well-maintained product. A founder can build across categories. The customer should still experience focus.