ABOUT
I work where the problem crosses boundaries.
Complex systems rarely fail inside one neat discipline.
The important problems often sit between them: where software meets infrastructure, product meets operations, model behaviour meets authority, or internal state meets the outside world.
For more than three decades, my work has followed those joins.
My job is to find what actually determines the outcome before the system hardens around the wrong assumption.
Tomaž Hrovatin known as Hodl Founder, Hodl Advisory
01 / 06 · Whole system
A working component is not the same thing as a working system.
2 → 30 people
I joined a two-person branch and helped grow it to thirty while remaining hands-on across software, networks, multimedia, clients, hiring and operations. If the network failed, the website was irrelevant. If the infrastructure, team or logistics failed, the project failed.
- software
- infrastructure
- people
- operations
That was the first lesson: the system fails at the joins, not according to the org chart.
02 / 06 · Learn the domain
I don't start with the tool. I start with the system.
one-person software company
As a one-person software company, Farma Kode took me deep into unfamiliar domains. I built a continuing-airworthiness management system for the Aeronautical Association of Slovenia, an intranet for Slovenia's Ministry of Defence, and an exchange simulation for Caltech students. There was nobody downstream to turn an unclear problem into a specification for me. I had to understand the domain first, then decide what the system actually needed.
- learn the domain
- operating problem
- system needs
- build it
03 / 06 · Consequence
Once software can move money, ambiguity becomes expensive.
300+ servers
Around 2015 I started building systematic strategies partly because I knew emotion was one of my own failure modes as a discretionary trader. The problem did not stay at the strategy layer. Strategy led to execution, DeFi, EVM infrastructure, block building and eventually more than 300 servers across locations and providers.
- strategy
- execution
- state
- infrastructure
- latency
Stale state, retries, timing and external outcomes stopped being architecture theory.
04 / 06 · AI as leverage
AI gave me leverage.
AI was not a new field for me to enter. It was leverage on work I was already doing. It let me move faster, work across more layers and build specialised collaborators around how I actually work. That became Clawblins.
Clawblins work with my real projects and knowledge. Different roles get different context, responsibilities and boundaries; deterministic services sit underneath the agents; important actions still require human authority.
Personality is part of the interface. It is not the control system.
- role-specific knowledge
- context + memory
- tools
- deterministic services
- permissions
- approvals
- human authority
05 / 06 · Capability → control
What can AI do?What is AI allowed to do?
As agent capability grew, capability became the less interesting question. The harder problem was what the surrounding system could safely allow them to do.
Building Clawblins and UnHodl kept bringing me back to these questions. Eventually I needed a clearer way to connect them. That became PROOF.
PROOFPremise · Role · Operation · Outcome · FailsafeRead PROOF ↗I didn't come to consequential systems through AI.
I came to AI through consequential systems.
06 / 06 · Why Hodl Advisory
I am not the deepest specialist in every room.
There are better ML researchers, security specialists, network engineers, quants and domain experts. A serious system needs them. My value is seeing where their answers meet — and where they conflict.
- Where model behaviour meets product policy.
- Where approval meets machine authority.
- Where application state meets external state.
- Where individually sensible decisions produce a system nobody intended.
The joins are where the important problems hide.
That is what I now do through Hodl Advisory: review consequential systems before assumptions harden into architecture.
Hodl Advisory provides architecture review and design, not implementation delivery. Your team or chosen implementation partner builds the system. My job is to help make the architecture worth implementing.
Bring me the problem before it becomes architecture.
You need a real system, a consequential decision and enough evidence to ask the difficult questions.