My Scientist’s Bias: Why I Had to Unlearn in Order to Build

This post is also available in Spanish.

There was something that didn’t add up for me in academia. I was fascinated by theory, by the elegance of models, but I found myself increasingly distant from a fundamental question: how are things built? How do you go from an idea on a blackboard to a system that works in the real world, that doesn’t break, that consistently delivers value?

I decided to do my thesis in applied physics, an attempt to get closer to “doing.” The experience was brutal and revealing. My days weren’t spent on the beauty of physics, but in a constant battle against the fragility of my own code. Simulations that ran differently each time, results I couldn’t guarantee, and a permanent feeling that everything was held together with duct tape.

This was 2016. The “reproducibility crisis” wasn’t a headline I was reading in Nature; it was the reality of my late nights. It was my frustration¹.

That was the breaking point. I understood that my true calling wasn’t to discover the next law of physics, but to understand how to build systems where every number matters and every result is verifiable.

The journey led me to places like JPMorgan, Qontigo, and Mercado Libre. I didn’t go seeking prestige; I went seeking answers. I wanted to see how it was done by the teams that couldn’t afford a rounding error. And what I discovered was profound: building robust software, especially in numerical domains, is not an extension of science. It is a discipline in itself.

That’s when I understood my own bias. The university had trained me for years to be an expert in analysis, in deconstructing complex problems to their smallest expression. That’s what a scientist does. But building is an act of synthesis². It’s taking pieces and composing a whole that is greater and stronger than the sum of its parts.

It’s like being a brilliant architectural theorist, capable of designing the most innovative blueprints and understanding structural forces at a fundamental level. But suddenly, you’re asked to lead the construction on-site: to manage the crew, to solve a material shortage, or to adapt to an unexpected downpour. Your knowledge of the blueprint is vital, but the skills to actually erect the structure in the real world are entirely different. I had to learn to be the builder, not just the architect.

Phorma³ is the crystallization of that journey. It’s my answer to the frustration I felt during my thesis and that I see replicated in so many R&D, finance, and data science teams. Teams full of brilliant people, held back by the friction of tools and processes that aren’t up to the level of their talent.

This isn’t about finding a magic formula. It’s about applying a proven engineering discipline, but adapted to the specific context of research and development. It’s knowing which practices to use, how, and when. Phorma is the map I wish I’d had ten years ago, so I wouldn’t have had to draw it blindly.

And this is where it all connects to a larger mission. I know the reality of science in Argentina and Latin America firsthand: talent is abundant, but funding is scarce. On the other hand, I see an industry with capital, desperately seeking the kind of intellectual capital that our universities produce in droves.

The real potential isn’t in the industry simply “hiring” scientists to stop them from being scientists. It’s in building a bridge⁴. A bridge where the rigor of scientific thought can merge with the discipline of software engineering to create something new. Something that generates economic value and, at the same time, advances knowledge.

Phorma is my first attempt to build that bridge. It won’t be easy. But it’s a deep conviction born from my own story.

If any of this resonates with you, if you see brilliant architects frustrated because the building won’t go up, let’s talk.

Notas