From One Big Project to Dozens of Small Ones: A Portfolio Model for Games

Developer? To some extent. Marketer? Definitely. SEO specialist? I've been doing that for years. "Vibe coder" is a fashionable term right now, and it describes part of my work fairly accurately too.

But the closest word is probably "producer." I come up with products, take part in building them, handle the promotion, watch the analytics, experiment with SEO and ASO, and try to understand why one project starts to grow while another doesn't.

Over the past year, my main focus has become small casual games and apps.

After 15 years, I had to start over

Before this, I spent roughly 15 years promoting online projects. A year ago that chapter of my life ended, and a simple question appeared: what next?

I wanted to work on my own products. But I didn't want to build yet another huge startup that needs a big team, investment, and several years before you even find out whether anyone needs it at all.

Games looked like an interesting direction.

Not AAA, and not an attempt to invent the next Fortnite. The opposite, in fact — I was drawn to the simplest, most timeless things: sudoku, solitaire, tic-tac-toe, jigsaw puzzles, math games, and other small casual projects.

These games have a quality I really like: they don't have to be trendy. People played sudoku yesterday, they play it today, and they'll almost certainly still be playing it in ten years.

The first big project turned out to be a good lesson

Paradoxically, I arrived at the idea of building small products after trying to build a big one.

We built our first game project almost like a full-blown portal. Sign-up, an internal currency, ratings, a pile of features, a fairly complex interface.

We spent a lot of time on it.

What we ended up with was a beautiful but heavy product. The site was complicated for users, slow, and poor at picking up search traffic. And promoting a project like that by other means would have required an entirely different budget.

About six months of work essentially had to be thrown away.

In the end I rebuilt the site from scratch.

That's when the principle I try to follow now took shape: first build a minimal product that does one thing well, and only complicate it later. Don't construct an enormous system and hope someone will need it. Test the simple idea first.

Why I build dozens of apps instead of one

There's another reason I like the small-product model. I don't want to bet everything on a single idea.

If you spend six months building one app and then find out people don't need it, those six months are all but lost. If you launch ten small experiments in the same time, the situation is completely different.

One gets no traffic. The second converts installs badly. The third unexpectedly starts to grow on Google. The fourth does well in the App Store. The fifth suddenly finds an audience in a country you never even considered.

Each project becomes a separate experiment.

Today our portfolio already includes around 55 apps for iOS and Android and roughly 30 sites and web projects — some existing as both a site and a mobile app, some for now only as a web version. The whole collection lives on my portfolio, Ivan Lukichev. Longer term, I'd like to have a portfolio of around 50–100 apps and a comparable number of web projects.

Not for the sake of the number itself. What interests me is a system in which each small product is capable of finding its own audience on its own.

When a school chooses your app

The most rewarding moments, meanwhile, aren't necessarily about money.

One day we noticed an unusual cluster of installs of our kids' sudoku app coming from Hong Kong. Judging by the data, the app had been installed en masse in one or several schools — around two hundred installs.

Two hundred downloads don't move a business by themselves.

But the thought that somewhere a teacher, an administrator, or some other responsible person had looked at the product, decided it was fine to give to children, and then had it installed for their pupils — that mattered to me far more than the number. It means a complete stranger trusts your product enough to hand it to children. For a small independent developer, that kind of thing feels especially good.

The hardest part is the waiting

If I describe my typical workday, it looks fairly strange: woke up, sat down at the computer, got up from the computer, went to sleep.

I've probably never worked this much before. And yet I don't really experience it as work. I genuinely enjoy making these projects. On top of that, having many projects saves you from routine — today you're working on sudoku, tomorrow on solitaire, then you're analyzing search queries, then changing an app, building a new landing page, or testing a completely different mechanic.

The most unpleasant part of this work is how slowly the feedback arrives. You change a site — now you wait for Google. Sometimes a few weeks, sometimes months. You submit an app — you wait for Apple. You change something in Google Play — you wait again. Even a small decision turns into a loop of "did it, wait, measured, did it again." And when several dozen projects exist at once, there's almost always something whose results you're waiting on.

SEO instead of betting on luck

My strategy right now is largely built around search traffic — and I think of SEO more broadly than classic website promotion. There's Google. There's search in the App Store and Google Play. There's localization. There are different countries and languages. There's the link between a web product and a mobile app.

What I find especially interesting is the idea of creating products that can pull in an organic audience for years. I don't want to buy each user over again. If someone searches for "sudoku for kids," "solitaire online," or a specific small game and finds my product, that model is much closer to what I want.

So one of my long-term goals is to reach roughly 100,000 search visitors a day across the whole portfolio. Because from there the logic is fairly simple. If there's search traffic, there are users. If there are users, there are app installs. If there are installs, you get a real chance to experiment with monetization.

But where's the money?

It's funny, but if you asked me what I want more right now — money, audience, or the enjoyment of the process — I'd probably choose the last one.

Of course, any product has to earn eventually. But right now I'm far more interested in the process of building this system. Launch a small idea. See whether people need it. Find the search demand. Build the web version. Release the app. Translate it into other languages. Watch which country it unexpectedly starts growing in. And then repeat it all from the start with a new idea.

Maybe in a few years it'll turn out that out of a hundred small experiments, only ten became genuinely notable products. I'd be perfectly happy with that result.

Because the main thing my first big, failed project taught me is this: you don't have to know in advance which idea will take off. It's far more useful to build a process that lets you find out cheaply.