Infrastructure that's hard to build.
Most engineering teams can ship features. Far fewer can solve the architecture underneath — the part that breaks at scale, the systems that have to hold under real load, the AI infrastructure that doesn't exist as an off-the-shelf product yet.
That's the work I take on.
01 / The problem
You don't need another pair of hands. You need someone who's already solved this.
You're here because something in your stack is past the point where adding engineers helps:
- 01
Your backend buckles under load you didn't have six months ago, and the fix isn't a bigger instance.
- 02
You're building on top of AI agents, inference, or model-serving — and the infrastructure for it doesn't come in a box.
- 03
Your architecture made sense at v1 and is now the thing slowing every release down.
- 04
You have the product vision but no one on the team has built systems at this depth before.
These aren't problems you outsource by the hour. They're problems you hand to someone who has carried the weight before.
02 / Who I am
I've been the CTO who had to make these calls.
I'm Max Petriev. Ten years in software, and before that, pure mathematics — which is not a footnote. A mathematician's intuition is what lets me design systems that hold together: correct by construction, not patched until they pass.
I co-founded and ran engineering at TheStage AI, where the entire business was making AI inference faster and cheaper — the hard end of ML infrastructure. Before that I led engineering at VK and Delivery Hero, on systems at a scale where “it works on my machine” stops meaning anything.
I've spent those years on both sides of the work: deep in the code, and accountable for the architecture above it. I still write it; I've also led the teams that ship it. That combination is rarer than it should be — most engineers who reach this level have stopped doing one or the other.
What that means for you: I've sat in your chair. I've been the one accountable for whether the system holds, not just the one writing tickets. And I know where outside help usually goes wrong — because I've hired it.
03 / What I do
What I take on
Scalability & high-load architecture.
Systems that have to survive real traffic — designing them, or fixing the ones that didn't.
AI agent infrastructure.
The orchestration, state, memory, and serving layers that production agent systems need and that no SDK gives you out of the box.
Inference & ML serving.
Getting models into production cheaply and fast — the work I built a company around.
Backend systems at depth.
Distributed systems, data pipelines, the load-bearing parts of your stack.
This is not a menu of everything. It's the work where deep experience is the difference between a system that holds and one that quietly costs you.
04 / How it works
How it works
I take ownership of a defined problem, not a seat on your team. You hand me a challenge with clear edges; I'm accountable for the outcome inside it.
Most engagements start small and de-risked:
- 01
Audit.
A paid, focused look at your actual problem. You get a clear read on what's wrong and what it takes to fix — useful even if we stop there.
- 02
Proof.
A working demonstration on the hard part, so the path is proven before you commit to it.
- 03
Build.
Full delivery of the module or system, owned end to end.
You always know what you're getting and when. No open-ended retainers, no body-shop hours.
Bring me the hard part.
If you have an engineering challenge that's past the point of throwing people at it, tell me about it. The first conversation costs you nothing but the time to explain the problem.