About
I like building the smallest real version.
I'm Ferran, a founder and engineer. I'm currently building Zodus and co-running Triad Labs.
What I'm building
Zodus is the thing I think about most. It's a context and coordination layer for AI-native companies — shared memory, tools, workflows, and a live sense of what is actually happening inside the business. The premise is simple and, I think, under-appreciated: agents fail at real work far more often because they lack context than because they lack capability.
Alongside that, I co-run Triad Labs, where we build and operate production AI products with ambitious teams. Triad keeps me close to systems that have to survive contact with real users, which is where most of my opinions come from.
How I became a builder
I'm originally from Pondicherry, and I came to this the long way round — by making things. Products, side projects, open-source patches, hackathon entries over a weekend. None of it was a plan. It was a habit, and the habit compounded.
Somewhere in there I did an MS in Computer Science at Northeastern University, which gave me the formal grounding. But the part that actually changed how I work was shipping: the gap between a system that looks correct and a system that holds up is where I learned the most.
The problems I go after
I'm drawn to problems where the hard part is coordination rather than computation — where the difficulty is that information is scattered, ownership is unclear, and nobody has the whole picture. That's true of companies, and it's about to be true of companies full of agents.
I've worked across AI systems and agent infrastructure, full-stack products, and mobile software. The range matters to me. Knowing how the model behaves, how the queue behaves, and how the interface feels in someone's hand is what lets you make a real product decision rather than a local one.
What I'm actually interested in
I think the interesting question isn't whether agents can do the work. It's what a company becomes when they can — how decisions get recorded, how ownership is assigned, how a person stays meaningfully in the loop without becoming a bottleneck. I don't think anyone has a settled answer yet. I'd like to be one of the people who works it out in public.
Operating principles
How I work
I build the smallest real version.
Not a mockup, not a deck. Something that runs and can disappoint someone.
I put it in front of people.
Early, before it's flattering to do so.
I learn from what breaks.
The failure modes are the specification. Everything else is a guess.
I explain the tradeoffs.
Every decision costs something. Saying what it costs is part of the work.
I keep ambitious people close to the work.
Distance from the product is where teams go wrong.
If you're building something along these lines, I'd like to hear about it.