About

I am an independent consultant. I work on systems where money moves in real time and being wrong is expensive: telecom billing, telephony, trading platforms.

Where I started

LITMO in St Petersburg, then straight into telecom in 1993. At that point there was no billing system a fixed-line operator here could simply buy. You specified what you needed, you argued it through with whoever built it, you ran it, and when it produced a wrong invoice you were the person the finance department came to find. That turns out to be an unusually good education. You learn very quickly which parts of a system you are allowed to be clever about and which parts have to be boring.

Why real-time systems

Most software forgives you. You ship a bug, you fix it on Tuesday, nobody outside the team notices. Billing does not forgive you: a rating error does not stay a bug, it becomes an invoice, and an invoice becomes a customer relationship. Telephony does not forgive you either: the call is happening now and there is no retry. An execution stack under load will punish an allocation you did not think about.

What I find interesting is exactly that constraint. When you cannot fix it afterwards, you have to think about it beforehand: invariants, failure modes, what the system does when a dependency lies to it. That is the part of this job I have not got bored of in three decades.

How I work

One person, holding the whole stack: switch protocols, the data model, the services in between, the frontend the operator looks at, and the deployment underneath. Most of the overrun in systems like these is not inside any one layer, it is in the seams between the teams that own each layer. With one person there are no seams, and no meeting where two departments discover they assumed different things about a timestamp.

The trade-off is honest: I do not scale to twenty engineers, and I take a small number of engagements at a time. I work remotely, in English or Russian, mostly with European and Middle Eastern clients.

Things I built recently

A system you operate yourself teaches you things a system you hand over does not, so a few run outside client work.

Engagement model

I take defined engagements with an end: an architecture review, a rescue, a build. Each one finishes with your team holding the result and the reasoning behind it. That shape is deliberate, and it is what keeps the previous section true.

Contact

Email: hi@realgeek.biz
LinkedIn ·GitHub ·Telegram

Describe your problem in three sentences. I'll tell you honestly whether I can help.

If it isn't my kind of problem, I'll say so and point you somewhere better. Direct email works too: hi@realgeek.biz.