I'm an empathetic builder. I use technology to empower people.
I'm an 8-year full-stack product engineer based in Buenos Aires. I started in enterprise delivery, grew inside product teams, and now work closest to founders and users. Recently I've helped pivot an Amazon seller platform into AI workflows, taken a nontechnical founder's Spanish reading app to web and mobile subscriptions, and started building Casamo, my own stay-decision tool for remote workers.
How I work
The value is rarely just output. It is judgment about what to build, what to leave out, and how the thing feels to use.
I do my best work when I can talk to the people we are building for, not just read a ticket. That is usually where the real product decisions hide.
Scope, UX, architecture, and the code that ships. I like making those calls in the same conversation instead of throwing work over walls.
Most of my recent work is with LLMs: RAG, agents, evals, and voice. The hard part is rarely the model. It is the product and UX choices around it.
01
I start with the real constraint.
Most work should begin with the actual bottleneck, not the feature list. That is usually where the leverage is.
02
I reduce before I build.
The first version should be smaller and clearer than what most teams reach for at the start. That is how good products stay shippable.
03
I explain tradeoffs directly.
Scope, UX, architecture, and implementation decisions only help if they are understandable. I do not hide the reasoning behind technical language.
What I'm building toward
Long term, I want to build a product of my own that supports me and gives me room to help other people learn how to build. Buenos Aires has made that feel less abstract: a local indie hacker community, people trading feedback, people shipping real things. Casamo is my current practice ground for that.
Right now, I'm looking for a team where I can use AI to solve real user problems without being far away from the customer, the product decisions, or the code.
Point of view
01
Know what you want before you ask AI to help.
AI can make you faster, but it cannot decide what matters for you. If you do not know who you are building for, you can build the wrong thing faster.
02
The first version is easier now. Choosing is still hard.
One person can get surprisingly far now. The hard part is choosing a real problem, finding the simplest shape for it, and getting it in front of people.
03
Stay close to the person using it.
The useful product decisions usually hide in conversation with the user. By the time a problem becomes a polished ticket, a lot of the meaning has already been lost.
04
Fast work needs guardrails.
Tests, linting, evals, automated QA, logs, and release checklists matter more when code is moving faster.
05
Autonomy matters because context decays.
I do my best work when I can see the problem, form a view, and act on it. Every handoff between observation and implementation loses something.
06
The indie hacker path is honest.
You either have something people want or you do not. Brutal, but clean.
Background
Large delivery environments, a product-led team, and my own studio, where owning the outcome mattered as much as the code.
Learned structured delivery, stakeholder management, and what larger organizations optimize for when the systems are real.
Front end engineer inside a strong product team, where growth, UX, and implementation had to stay connected to each other.
My own studio, where I have shipped MVPs, taken AI products to paying customers, and built internal tools end to end.
Along the way I've built tools to solve problems I kept running into: remote control for agent workflows, session recall, mailbox context, safer automation. They're collected on the tools page.
See tools and experimentsIf you're building something I might fit, I'd love to hear about it
I'm looking for a team building a product worth caring about, where an engineer who can own the whole arc would help. Email is the fastest way to reach me. I also take on select freelance and fractional work through HC Studio.
Get in touch