What I believe

Not a manifesto. Just things I think are true and try to act on.

These are my working convictions about AI, building products, and what makes work worth doing. They've come from eight years of building, two years of freelancing on my own, and living far enough from the tech bubble to see things differently.

Knowing what you want is the most important skill.

Everyone keeps saying taste is now the most important skill. I find that framing a bit annoying. It stops the question too early. Taste doesn't do much if you don't know what you want to build in the first place.

Knowing what you want requires self-knowledge most people don't develop deliberately. It means noticing what makes you genuinely excited versus what makes you dread the day ahead. If you can't tell the difference, no amount of craft will save you from building the wrong thing really well.

AI has made this more visible. When implementation is cheap, the hard part shifts to intention. Building the right thing requires a kind of self-honesty that tools can't give you.

Building is easy now. Choosing is hard.

A few years ago I watched someone build a working application without knowing how to code. Not a demo, something real. That's when I understood things had actually changed. The gap between an idea and a working product used to require months and a team. Now it mostly requires clarity about what you're building and why.

That changes what matters. If anyone can build, execution becomes table stakes. What you chose to build in the first place is the whole game. A simple product that solves a real problem will outlast an impressive one that solves a problem nobody has.

When I eventually teach people how to build, the first session will be about finding a problem worth solving. Code comes after.

The person is always the point.

Buenos Aires has a different relationship to technology than the places I've lived before. It's more social, less startup-obsessed. Living here for years has reinforced something I already suspected: technology is supposed to help people, and you have to keep that visible when you're building.

It's easy to forget. Engineers, myself included, can get absorbed in the craft. The architecture, the performance, the clean solution. And then the person using the thing has to fight their way to what they actually came for.

Good technology gets out of the way. When it's working, the person using it stops thinking about it entirely. That's the goal.

Autonomy is a condition for doing good work.

Good decisions come from people who are close to the problem and allowed to act on what they see. Every layer you add between observation and action costs you something.

I do my best work when I can talk to a user, form a view, and act on it. Information degrades at each step of retelling, and by the time a spec reaches me it can be several steps removed from the actual problem.

It's also why I prefer small teams. I want the accountability to actually connect to the work. When a team is large enough that nobody can see the whole thing, you get a lot of motion without much direction.

The indie hacker path is one of the most honest ways to build.

I'm drawn to people who start from zero and build their way to a real income, one user at a time. What I find compelling about that model is the honesty it demands. You can't hide behind a roadmap. You either have users or you don't.

Larger organizations find ways to soften that feedback. An indie builder doesn't have that option. Some days that's brutal; other days it's the clearest feeling in the world.

That's the version of this work I want to get to eventually. And when I'm ready to teach, I want to teach how to get from an idea to someone actually paying for it.

If any of this resonates, I'd like to hear from you

I'm looking for a team building something worth caring about, where an engineer who thinks this way would help. Email is the fastest way to reach me.

Get in touch