Lessons From Running a Real Business That Made Me a Better Engineer
Personal Essay
I've hosted regional fencing tournaments for three years through CozmX Fencing. Dozens of events. Hundreds of competitors. Real money, real logistics, real failure modes that no rollback command can fix. And I'm convinced this made me a sharper ML engineer than any Kaggle competition or coursework ever could.
CozmX Fencing — By the Numbers
Systems Fail at the Seams, Not the Centers
A tournament isn't one problem. It's registration, bracket generation, venue coordination, referee scheduling, real-time scoring, and parent communication — all stitched together with duct tape and trust.
The breakdowns never happen inside any single function. They happen in the handoffs.
The Cascade
The Engineering Parallel
I see the exact same failure pattern in production ML pipelines. Models don't fail. Integrations fail. I learned to think in handoffs before I ever deployed a multi-agent system, and that instinct has saved me repeatedly at OptiU.
Your System's Real User Doesn't Care About Your System
Fencers and their families don't care about my bracket algorithm. They care that the event runs on time, that results are fair, and that their kid's name is spelled right on the scorecard.
That reframing changed how I build ML products.
What Engineers Optimize
What Users Actually Care About
Orienting around the downstream consequence, not the technical metric, is something I internalized on gym floors long before I applied it to production code.
Resource Allocation Under Real Constraint
At a tournament, you don't get to scale horizontally. You have the referees you have. The strips you have. The hours you have. You optimize or you fail publicly.
That scarcity mindset became my default engineering posture. At a startup with no dedicated MLOps team and limited compute, I don't reach for the biggest model or the most complex architecture. I reach for the cheapest decision that still works, then I iterate.
Same Mindset, Different Domain
The Core Lesson
Running a business with real operational stakes gave me something most junior engineers lack:
An allergic reaction to abstraction without accountability.
Every system I build, I ask the same question I ask before every tournament: if this breaks at 2 PM on a Saturday with 200 people watching, what happens?
That question changes how you write code.