Six Products, Two Founders: The Honest Case For and Against Spreading Out

Every piece of advice for a small team says the same thing: pick one product and focus. It is good advice. We have read it, we agree with most of it, and we have not followed it. Unileaf is two founders and a small team in Baleshwar, and we run six products: BartO, WPfolk, StoryMet, Poetriz, Gofeh and Qtron, which has not launched yet.

This is not a defence of that choice. It is an attempt to lay out the trade-off plainly, because most writing on the subject is either a warning ("you will finish nothing") or a boast ("look at everything we ship"). Neither is much use to someone who is deciding.

So: the real reasons a small team spreads out, and the real costs of doing so. We are the example, not the hero of the story.

Why anyone does this

The products share more than you would think

Every product needs a server, a deployment pipeline, a login system, a way to send email, a way to take backups. The second product costs far less to set up than the first because the pipes already exist. By the fourth, the shared plumbing is most of the technical work, and each new product is mostly the part that is genuinely new.

That is not, on its own, a reason to build six products. But it puts the price of the second one well below what people expect, and a lower price changes the decision.

One kind of work can pay for another

Some products earn on a predictable schedule. Others are the sort nobody pays for early: a poetry site, a reviews site, a tool that needs many people using it before it is worth anything to anyone. We are not going to say which of ours falls where. That is exactly the kind of claim this post should avoid, and it is nobody's business but ours. The structural point holds regardless: if one kind of work covers the bills, the slower products get to exist for longer than they would as companies of their own.

You do not know which idea has legs

The advice to focus assumes you already know what to focus on. Often you do not. Several of our products began as side projects before the company existed, built because someone wanted them, not because anyone had picked a winner. Running a few of them in the open, for a while, is a way of finding out. It is slower than a proper experiment and more honest than a guess.

Founders have more than one itch

This one is rarely admitted. Two engineers started this company, and the products are simply what they were interested in: used goods changing hands, WordPress, books and films, poems, luggage space, people buying things together. Telling a founder to drop five of those for the sake of tidiness works on paper. In practice the dropped ideas do not go away. They get built at midnight anyway, worse, and without a plan.

What it costs

Attention does not divide cleanly

Six products do not each get one sixth of the team's attention. Whatever is on fire gets most of it, whatever is quiet gets almost none, and the split changes week by week. A product can go a month without anyone thinking hard about it. The people using it do not know that, and it is not fair to them.

Six roadmaps is six sets of promises

Each product collects things people have asked for, things that are half-built, things we said we would do. With one product that list is a plan. With six it is a queue that never empties, and choosing what to do next becomes a job in itself. We do not have a clever system for this. Mostly we pick whichever item someone has complained about most recently, which is a habit, not a strategy.

The temptation to never finish anything

This is the cost that actually worries us. Starting a product is exciting; the last twenty per cent is not. When there are five other places to put your attention, walking away from the boring end of one product is very easy, and you can tell yourself it is prioritisation. Qtron is the one of ours that has not launched, and we know how easily "not yet" turns into "not ever" when there are five other things to do.

Nobody outside can tell what you are

A company with one product is easy to describe. A company with six sounds, to a client or a job candidate, either bigger than it is or less serious than it is. We are neither a large company nor a hobby, but explaining that takes a paragraph, and most people do not give you a paragraph.

What we would tell someone deciding

• If the products genuinely share infrastructure, not "could" but do, the second one is cheaper than you think. If they do not, you are starting from scratch each time and the arithmetic is against you.
• If none of them pays the bills, you are not running several products. You are running several hobbies, and it is better to say so.
• Decide how long a product may sit untouched before you either work on it or shut it. We have not always done this. We should.
• Do not let "we are learning which idea works" become a permanent excuse. It is worth a year or two. After that, you know.

Why we still do it

Because the reasons above are real, and because, weighed against the costs, they still come out ahead for us: narrowly, and not on every day. The shared infrastructure is real. The chance to see which product people actually want, rather than guess at it, is real. And the founders' interests are what they are.

We would not recommend this to most small teams. We are not certain we would recommend it to ourselves, starting again. But we chose it, we know what it costs, and for now we are keeping it. If that changes, we will write that post too.