Mehul

Two Years Building Mettalex: What I Learned Owning a 0→1 Product End to End


It started with a call. Three of us: me, Humayun, and Chirag, just talking, no agenda, about what autonomous systems could actually be used for. We'd worked together before so we skipped the awkward getting-to-know-you phase and went straight into the deep end. That call turned into Mettalex. And Mettalex turned into two of the most formative years of my career.

I owned this product end to end. Roadmap, architecture, team, releases, community, incidents, patents. The wins and the hard lessons both have my fingerprints on them. That's what makes this worth writing about.

The First Experiments

The earliest days were just experiments framed as questions. Can we securely hand a wallet over to an autonomous agent? Can two agents trade with each other without a human in the loop? Simple questions with surprisingly hard answers.

I remember the first time a basic agent interaction completed end-to-end on Kubernetes. Objectively it was a tiny thing. But when you've been staring at a problem for weeks, that first moment of "it works" hits differently. That feeling is why I build things.

We started focused on a single chain, then deliberately moved to a chain-agnostic architecture. Blockchain was always just the settlement layer, the trust anchor underneath everything. The real problems we were solving were about coordination, execution, and state management between autonomous entities. That distinction matters to me because people hear "crypto project" and think the tech is the token. It wasn't. The token was just how we settled.

Lean Team, Fast Decisions

In the early phase it was three of us: me, one backend engineer, one frontend engineer. I cannot overstate how effective this was. When a team is small enough that everyone knows exactly what everyone else is thinking, you don't need alignment meetings because you're already aligned. Decision velocity is just... high. Naturally.

This phase taught me the thing I now believe most strongly about building: hiring right matters more than hiring fast. One wrong hire in a team breaks the whole dynamic. We got lucky and got it right.

Six months in we did a Discord showcase. The response was genuinely exciting, people loved what we were building, we eventually raised $1M in non-dilutive grant funding. The market was bullish and attention felt easy. I won't pretend that didn't feel good. It did.

The Thing I'd Do Differently First

We kept building after that. Got the system to beta. And then sat on it way too long before putting it in front of real users.

This is the decision I think about the most. I was optimising for completeness before exposure, waiting until it felt ready. But "ready" is a moving target you never actually reach. The cost of shipping early is some embarrassment. The cost of shipping late is spending months building things you didn't need to build, for users you haven't talked to yet.

Build in public. Ship before you're comfortable. Real users doing real things will break your assumptions faster than any internal review ever will. I knew this intellectually. I didn't practice it early enough.

A New Architecture, Two Patents, and a Very Unstable System

When beta users started actually using the product, we discovered security gaps we hadn't thought through carefully enough. It forced a real architectural rethink, not a patch, a proper redesign.

The new architecture was novel enough that we filed two patents around how autonomous agents coordinate and settle transactions across distributed systems. One has since been granted. I'm genuinely proud of that. It wasn't a defensive move, the architecture was actually a new way of thinking about the problem.

But while we were doing this deep work, the system was unstable and we were doing monthly releases. From the outside, monthly releases look like inactivity. The community started saying we weren't working. That stung, because we were working harder than ever.

The frustration forced a good change though, we moved to weekly releases, sometimes twice a week. That cadence shift changed everything about how the community perceived us. Same work, different communication rhythm, completely different reception.

Cadence is a communication tool. I didn't fully understand that until I lived through what silence feels like from a community's perspective.

When the Bugs Caught Up With Us

The team grew as we took on more. At peak: me plus three backend engineers, two frontend engineers, a devops engineer, a marketing manager, two designers, and a QA engineer. We were going to conferences, Cosmoverse, ETH India, Token 2049. Rolling out features constantly.

And then the bugs caught up with us.

I had been adding features faster than we were stabilising them, and one day I opened Jira and it was completely overrun. I remember that feeling clearly, the sinking realisation that we'd been trading stability for velocity and now had neither. More and more engineering time went toward firefighting. Progress slowed visibly.

We stopped releases entirely. Restructured the codebase. Focused purely on stability. Tested with over 5,000 agents in production. Eventually the system was genuinely solid, more solid than it had ever been.

But here's the brutal reality of infrastructure work: you can't demo a stable system. There's nothing to show. Community sentiment was at an all-time low precisely when we were doing some of our best technical work. That gap between internal progress and external perception is one of the hardest things to manage in early product work.

Ship stable features in small chunks. Don't bundle. Every feature you bundle raises the stakes of every release and multiplies your blast radius when something breaks.

Making Invisible Work Visible

We got better at communicating. Monthly written updates to the community. Public release logs for every small change. Twitter sessions, Discord AMAs, developer calls. None of this came naturally to a team of engineers. All of it mattered.

We also, finally, started doing UX interviews. We had built a trading interface without any of us being actual traders. Predictably, it wasn't great. The interviews surfaced obvious things we'd completely missed. These should have happened in week one. They happened in month fourteen.

Communicating progress is not a distraction from building. It's part of building. Internal wins are invisible unless you narrate them.

How It Ended

The autonomous agent landscape evolved quickly. A decision was made to discontinue Mettalex as an actively operated trading product. Competitive pressure, fragmented liquidity, and the difficulty of bootstrapping a derivatives venue in an uncertain regulatory environment made continuing operations the harder path to justify.

The technology itself held up. A portion of the agentic infrastructure is being considered for broader use within the ASI ecosystem. When the work you built gets recognised as reusable at that level, that means something, even if the product didn't reach the scale we aimed for.

If I could go back, I'd go to market earlier. Ship smaller. Keep the feedback loop tight from day one. The best thing you can do for a product is put a real user in front of it as fast as possible.

But I also wouldn't trade the experience. Leading a team, filing patents, shipping production systems, building something from a call between three people into a real thing in the world, that's valuable. I learned more in those two years than I had in the five before them.

I'd do it again.

TLDR; Lessons