Feranor

I Run a Production HFT Platform Alone. Here's My Governance Stack.

I operate a high-frequency trading platform in production, by myself. No team. No on-call rotation. No one to absorb my mistakes, and no organizational inertia to slow down the consequences of a bad decision. Every choice is load-bearing.

The conventional wisdom says governance is what large teams need: process for coordinating many people. A solo developer should optimize for speed and skip the ceremony.

I believe the opposite, and the platform is my evidence: a solo developer running a mission-critical system needs governance more than an enterprise does. Here's what that looks like in practice.

The system

Krachen is an event-driven trading system: a Gateway module handling all external market data providers, isolated Strategy modules (one per trading algorithm), a Silo module built on the actor model for stateful computation, and a Master Module that orchestrates deployments and infrastructure without containing a single line of business logic.

HFT is an unforgiving domain. Latency matters in microseconds. State must be exact. Failures cascade faster than humans react. The market doesn't pause while you debug. That makes it a brutal and honest laboratory: every governance idea I have gets tested against immediate, financial feedback.

What governance means when the team is one person

Concretely, every module has its own repository, its own pipeline, its own contracts. Nothing crosses a module boundary except through a formal, versioned interface. The Gateway is the only component that touches external market feeds. It validates, normalizes, and publishes a typed internal event stream. Strategy modules consume that contract; they never see a provider's raw format. When a provider changes its protocol, exactly one module changes.

Strategies are fully isolated from each other: a bug in one cannot affect another, and deploying a new one touches nothing that exists. Every deployment goes through pipelines; every environment is defined in code; no credential is shared; nothing is provisioned by clicking in a portal.

And yes, I review my own pull requests. I maintain contracts that only I consume. I document modules whose only reader, for now, is me.

"But you're alone, who is this all for?"

Three answers, all learned the hard way.

It's for me, six months from now. The solo practitioner who builds a system in 2026 is not the same person who maintains it in 2028, even if the name is the same. Time changes context as thoroughly as team changes do. The documentation I write today is the handover to a future me who will have forgotten every implicit decision I'm currently carrying in my head.

It's for the moment that proved it works. The clearest validation wasn't a crisis. It was the opposite. I needed to add a new module, a context component pushing events into the Silo's synchronization tasks. In an ungoverned system, that means understanding the whole codebase before touching anything, plus the risk of breaking something invisible behind an implicit dependency. In Krachen it took minutes. The boundary was clear, the contract with the Silo already defined, the pipeline ready. I wrote the module, it plugged in, it worked. The framework didn't tell me how to implement the logic. It told me where the edges were.

Knowing the edges made everything inside them feel lighter, not heavier. That's when I understood that good governance doesn't create rigidity. It creates room.

It's for the growth that hasn't happened yet. When a second developer joins, they get onboarded onto one Strategy module, within a defined scope. They don't need to understand the Gateway, the Silo, or the Master Module, just their module's contract, standards, and pipeline. The governance that supports a five-person team is already running for a one-person team, because the structure was never about headcount. It was about clarity. Structure scales; intuition doesn't.

This also turned out to be exactly the infrastructure AI agents need. Agents are contributors: scoped access, supervised output, human approval at merge. A system already organized around boundaries and contracts absorbs them naturally. A system organized around one person's intuition has nothing to hand them.

The honest caveat

I won't present my own platform as independent proof of my own framework. The two evolved together, and that would be circular. What the platform provides is something more modest and more useful: internal consistency. A live system, operating under real market conditions and real governance constraints, long enough to show where the framework holds and where it needs refinement.

What I can say with confidence: the cost of the discipline is small, constant, and front-loaded. The payoff is a system where iteration is fast because the boundaries are strict, where any failure is contained by design, and where the answer to "what changed?" is always one lookup away, at any hour, with no one to ask but the system itself.

When you're alone, the governance isn't bureaucracy. It's the teammate.