Projectologist vs Founder: why I run ten projects instead of one

This quarter I launched eight projects. By the end of the year, six of them will probably be dead or on life support. This is not a confession. It is a business model.

I am not a founder. I am what I call a projectologist — someone who builds in portfolios, thinks in brand architectures, and treats each new project as a parallel bet rather than a life mission. Understanding this distinction took me years and more failed monomanias than I want to count. Now that I have accepted it, the work has become both more productive and considerably more honest.

What a projectologist is (and is not)

A founder builds one thing. They obsess over it for years, say no to everything adjacent, and believe — genuinely — that this product will win a significant market. This is the archetype that startup culture is built around, and for good reason: it works when the market is large enough, the insight deep enough, and the person patient enough.

I am not that person.

I am energised at the start of things. When a niche reveals itself — a gap in the market, an underserved keyword cluster, a regulatory arbitrage nobody has packaged — I can move from idea to first version in a weekend and have something indexing by Monday. I can see brand architecture before the product exists. I can position something before it has a single user.

What I cannot do as naturally is the quiet, relentless work of grinding a single thing from traction to dominance. I understand this is a limitation. I am not romanticising it.

The portfolio in practice

Right now I run a collection of projects across Estonia and two other EU markets. The mature ones cover lending comparison, document templates, business banking tools and a handful of affiliate content properties. The newer ones are experiments in AI-native services: narrow tools that do one thing well and charge per use.

The document template service — dokud.ee — is a useful example of the model working. The insight was simple: Estonian-language legal document templates are scattered, dated and often behind a paywall that has not been updated since 2012. An AI layer that generates, personalises and exports a compliant template for €13 is worth paying for because the alternative is an hour with a lawyer. The model monetises from the first user because the value is immediate and the unit economics are clear. The one piece I would not shortcut on a paid product like this is the checkout-and-VAT layer — selling a €13 document across EU borders is exactly the merchant-of-record question that decides whether tax is your problem or the platform’s.

The counter-example — donatr.ee — is more instructive. I built a donation-link tool that grew to over 600 active users across dozens of countries, with new sign-ups arriving every day from organic search and — increasingly — from people asking ChatGPT for a tool like it. Usage was real. The problem it solved was real. The number of those users who had ever paid me anything was zero.

For a long time I told myself the funnel was just young. The analytics showed a couple of people reaching the Stripe checkout each day and not completing — a conversion problem, I assumed, the kind you fix with better copy and pricing. Then I actually read the server logs. Every upgrade attempt for the previous several days had been failing with a 500 error: I had passed Stripe a parameter that belongs to a different API, and it was rejecting the entire checkout request before the payment screen ever loaded. At least fifteen people had clicked “upgrade” and been handed an error message instead of a way to pay me. I had been carefully analysing a funnel that was physically incapable of converting, and I had not built the instrumentation to notice it was broken.

That is two failures stacked on top of each other, and both are mine, not the product’s. The first: I shipped without a real conversion mechanic — no list I owned, no tested upgrade path, no friction at the right moment. The second, more damning: I optimised a number for days without checking whether the number meant what I thought it meant. It is exactly why I now treat email capture as a launch requirement rather than a growth-phase nicety — and why I read the error logs before I trust a single line of a funnel chart.

Why many small bets beat one large bet (for me)

The honest case for a portfolio is not that it is more efficient. It is not. A single focused product, if the right one, will almost always outperform a portfolio on revenue per hour invested. The case for a portfolio is something different: it is appropriate for a specific type of person in a specific situation.

I run a portfolio because:

I learn faster across breadth than depth. Each project forces a new distribution channel, a new monetisation mechanic, a new audience. After running lending comparison for three years, I understand affiliate marketing at a structural level I could not have acquired any other way. After the donatr.ee experience, I understand the difference between user growth and monetisation readiness in a way that no book could teach. The portfolio is an accelerated curriculum.

Automation changes the economics. A project that requires daily active management is a job. A project that runs on content SEO, automated email and stable affiliate revenue is an asset. The goal of the first year of any project is to reach the point where it belongs in the second category. Projects that can be systematised free up capacity for the next bet.

Optionality has value in uncertain markets. AI is reshaping several of the niches I work in simultaneously. Some of those shifts will hurt positions I have built. Others will open new ones. A portfolio operator can pivot a specific project, kill it, or build alongside the trend — without betting the whole operation on a single prediction about where the market goes.

The honest cost of this approach

I want to be specific about what it costs, because most people who write about portfolios do not.

Dilution at conversion moments. I have already described the donatr.ee version of this, and it is not isolated. I run an invoicing tool with real users who create real invoices — and for months it had recorded exactly zero sales, for the simple reason that I had never switched the paywall on. There was no Premium to buy. “Zero revenue” did not mean “no demand”; it meant I had not built the part where money changes hands. That is the pattern in its purest form: a project reaches genuine early traction, and instead of staying to build the money layer, I am half-moved-on to the next thing. The discipline is forcing myself to complete a monetisation test before calling a project “running on autopilot.”

Under-tuning. None of my projects are as good as they would be if they had received two years of focused iteration. The document template service is useful; it could be excellent with six more months of work. I accept this trade. Others should not unless they genuinely can.

The coordination tax. Running 38 domains across multiple markets means a permanent overhead of renewals, server configurations, legal structures and compliance checks. Each one is small. Together they are a non-trivial management burden that a focused founder does not pay.

How I decide what to kill

The rule I apply every three months: binary decision on each project. Either increase investment (time, money, or both) or put it in maintenance mode and set a date to kill if it does not hit a defined threshold.

The criteria I use:

1. Does it make money, or is there a credible path to money within 90 days? Interesting traffic numbers without a monetisation experiment underway get no mercy.
2. Can I systematise it without being the bottleneck? If my involvement is required for the product to function, it is a job, not an asset.
3. Is the niche getting harder or easier to win? AI is making several content niches structurally harder. The right response to that signal is to cut early, not to work harder in a declining position.

Projects that fail all three get killed. Projects that pass two out of three get one more quarter. Projects that pass all three get focused investment.

Who this path suits — and who it does not

The portfolio model is not for people who want to build a category-defining company. It is not for people who need or want outside capital. It is not for people whose edge is relationship-depth in a single market.

It suits people whose edge is speed, systems thinking and distribution pattern recognition. It suits people who can ship a first version alone over a weekend and have the discipline to treat it as a hypothesis test, not a commitment. It suits people who are genuinely more energised by the first ten users than the ten-thousandth.

If you are reading this and recognising yourself, the question worth sitting with is not “should I do this?” but “am I honest about what I cannot do?” The portfolio model requires knowing your conversion weakness and building around it — not pretending it does not exist.

For me, that meant accepting that I will always be better at building and attracting than at converting. I now build the conversion mechanic before I call a launch “done.” It took one too many 300-user, zero-euro projects to wire that into the operating process.

Are you a focused founder or a projectologist? Where do you sit on that spectrum — and is that by design or by default?