Covario — a unified layer over exchanges

Covario was a fintech trying to solve a real pain for professional crypto traders: every exchange is an island. Order books, execution feeds, account state; all siloed behind incompatible APIs. The vision was a unified layer that would abstract that away and let traders (particularly high-frequency ones) operate across venues from a single interface.

I worked on Covario across three distinct chapters, each in a different role. The arc tells a cleaner story than any single engagement could.

Iteration I — Backend engineer

My first involvement was as a backend engineer at Brick Abode, which was contracted to help build the core infrastructure. I worked on systems design, test architecture, and the order matching engine, the component responsible for routing and reconciling orders across venue feeds.

This was early in my career, but technically intensive. I learned how to reason about latency at the protocol level, how matching engines handle partial fills and order priority, and what it means to write systems where correctness is non-negotiable.

Iteration II — Product Manager

The second chapter was a different kind of challenge. The team was tasked with building an MVP trading terminal for high-frequency traders, conceptually a Bloomberg Terminal for crypto. Think real-time order books, charting, portfolio state, and execution; all in one interface designed for professionals who live in their tools.

By then I had already moved into the PM seat, and worked hands-on across design and engineering. The product decisions were hard: HFT traders are deeply opinionated, and scope creep is existential on timeline-bound MVPs. I drove research sessions with actual traders, made tradeoff calls on what to cut, and kept design and engineering aligned week by week.

The MVP shipped on time and was delivered to the Covario team.

Bigger lesson: cross-team alignment at speed. The teams were scattered across the globe with varying levels of seniority. Managing stakeholder expectations upstream while keeping engineers unblocked downstream is its own discipline.

Iteration III — Exchange integrations

The final chapter was the one with the most interesting engineering problems. Once again, I wore the PM hat here, owning the product decisions while interacting with the engineering team.

The goal: populate the terminal with real-time data from multiple exchanges — Binance, Kraken, Gemini, and others — aggregated into a unified feed.

Latency was the essence. Every millisecond of delay between an exchange event and a trader’s interface is a competitive disadvantage. We built:

• Real-time WebSocket feeds per exchange, normalized to a common schema
• An order routing API — read/write — abstracting venue-specific quirks
• Aggregated order book views merging depth from multiple venues

The project was ultimately discontinued before reaching production scale. But the engineering work was clean: we had a working multi-venue pipeline and the architecture was sound.

What I learned

Three chapters, three kinds of hard.

As a backend engineer, the lesson was precision: systems that touch money don’t get to be approximate. You learn to read specs carefully, test edge cases obsessively, and ask “what happens when this fails?” before shipping anything.

As a PM, the lesson was scope. Feature creep is less of a planning failure and more of a communication one. The fix is not more process; it’s clearer ownership and the willingness to say no early and explicitly.

Finally, on the integration work, the lesson was the gap between a working system and a production system. Every exchange has quirks, rate limits, authentication edge cases, and undocumented behaviors. Integration work is translation work, and the translator is always underestimated.

A lot of responsibility across three years. A genuinely good experience.