EN

Ventures

I call myself an entrepreneur, not only an engineer — and there is a 25-year track record behind that word. Every business I have started since I was fourteen: the ones that paid, and the ones I wrote off — and what each of them taught the engineer I am today.

It started with a website, at fourteen

I was born in 1984. In 1998, at fourteen, I earned my first money from code: I built a website on commission and sold it. Then I built a few more — for individual clients and for companies — in the era when “a website” mostly meant static pages and a lot of careful hand-work. Nobody hired me onto a team. Someone needed a thing, I could make the thing, money changed hands. That is the entire loop of a business, and I had run it end to end before I was old enough to vote.

Then I went and learned the theory

Building taught me what works; school taught me why. I enrolled at the Higher College of Informatics at Novosibirsk State University (ВКИ НГУ) and spent two years on real engineering coursework — projects in C/C++, Java, and Pascal, plus the theory and the applied mathematics that all of IT quietly runs on.

From there I went into NSU’s Faculty of Information Technologies. I got in through an open mathematics olympiad, and strong results kept me on a fully state-funded place the whole way: four years for a bachelor’s, two more for a master’s. M.Sc. in computer science from one of the strongest programs in Russia.

I mention the diplomas not to flex them but for the timing: the engineering and the entrepreneurship grew up together. I never had a “now I’ll stop building businesses and become a serious engineer” phase. It was always both at once.

An exit at twenty-one

Around twenty-one, a friend and I designed and built a multiplayer online game from scratch — a browser game that grew to roughly a thousand active players. Then I did the part most hobby-project builders never reach: I found a buyer and sold it, not long after launch. Build something people actually use, then sell it — that lesson is worth far more than the single paycheck it produced.

Then I tried a lot of things

This is the part most engineers don’t have, and the part I’m proudest of. Over the years I started businesses in wildly different fields — on purpose. An honest list:

  • Cryptocurrency mining — hardware, power, heat, and margins that move while you sleep.
  • Confectionery — actually producing and selling sweets. A physical product with a shelf life and a supply chain.
  • A school of astrology — one of my long-standing interests, run as a real business with students and a curriculum.
  • A recurring eventfor rest and relaxation — hospitality and logistics, and people who either show up or don’t.
  • A weekly philosophy circle — small, stubborn, and good for the soul.
  • A youth producer center — where we helped young performers grow and turn their art into something commercial.
  • My own music project — a band. Yes, really.
  • A dropshipping business serving the US market.
  • Stock imagery — creating and selling images on Shutterstock and Adobe Stock.
  • Short-form video — a content business producing reels for the vertical-video era.
  • An agricultural business — growing and selling potatoes. Nothing teaches you about fixed costs and weather quite like a field.
  • Volunteer initiatives— helping organize cultural and entertainment events, where the whole “return” was in the experience.

Some made money. Several didn’t. I’m not going to dress that up — and that is exactly the point of this page.

What the write-offs taught me

Every one of these — the wins and the write-offs — handed me something I now use as an engineer, every single day:

  • A business is a system, and the bottleneck is never where you first look. Confectionery isn’t a baking problem, it’s a distribution problem. A game with ten thousand players isn’t a CPU problem, it’s a traffic problem. Finding the real constraint is the whole job.
  • You don’t optimize what you haven’t measured. Every venture that died, died of a number I had refused to look at honestly — margin, churn, cost per unit. I bring that to architecture now: measure first, then decide.
  • Shipping beats planning. The website at fourteen taught me the loop — make the thing, put it in front of someone, get paid (or get told no) fast. Most plans die of never meeting reality.
  • Most attempts don’t pay off, and that’s fine.The portfolio is the strategy. You take many honest swings, keep what works, write off what doesn’t — and carry every lesson into the next one.

Why this matters for the engineering

When I design a system, I’m not only asking “is this correct?” I’m asking “what is this actually for, where’s the real constraint, and what’s the cheapest honest way to prove it works?” Those are an entrepreneur’s questions. Two decades of building businesses — most of them small, many of them failures — is where that instinct comes from.

That’s why I say entrepreneur, not just engineer. The code is how I build today; the businesses are how I learned what is worth building. For the engineering side of the same story, start with about or my selected work.