CHAPTER IV — INTERNAL PROFILE
I'm not interested in being the one who "knows the most." I'm interested in being the one who best understands the problem.
BIOGRAPHICAL ESSAY AND PROFESSIONAL JUDGMENT.
Catamarca, engineering, and a hunger to learn
I'm from Catamarca, Argentina. I'm studying Computer Engineering at the National University of Catamarca. I'm in my third year. I learned the foundations at university and everything else on my own. Reading, trying, failing, and listening to colleagues. I work remotely from San Fernando del Valle de Catamarca.
Computer Engineering (UNCA, 3rd year). I learned React by watching Mauro code. The rest I picked up on my own, stumbling through each new project.
I started with small university projects. Today I build digital products for businesses and professionals at UXnicorp. I design, code, talk to clients, and manage the team.
I work remotely from Catamarca. Open to on-site opportunities if the project is worth it. I'm driven by the people I work with and the problems I can help solve.
Where I do everything. And I love it.
UXnicorp is a small web development agency. In a small agency there's no "design department" or "sales team." You do whatever needs to be done. And that's exactly what I did from the moment I joined.
Before writing a single line of code, I think about how what we're building should look and feel. I define palettes, typography, visual hierarchies. I build out the full interfaces. I'm not a trained designer, but I learned to design with judgment because someone had to do it and because I cared that what we delivered actually looked good.
React, Next.js, Astro, Tailwind, TypeScript. Whatever the project needs. I build frontends, backends when necessary, API integrations, authentication systems, databases. From a simple landing page to a booking system with atomic concurrency.
There are no middlemen. The person who designs and the person who codes is on the call. I listen to what they need, ask about what's unclear, and explain why we make each decision in terms anyone can understand.I find leads and sell. I identify businesses that could benefit from what we do, contact them, explain what we offer and why it can help them. I learned to listen, to understand what each one needs, and to offer solutions that make sense — not to sell for the sake of selling.
I coordinate tasks, define priorities, make sure we all know what needs to be done and by when. When something gets stuck, I unstick it. It's not a formal leadership role — it's what happens when you care that things turn out well.
At UXnicorp I didn't learn to be "a developer." I learned to be present in every part of the process. To not say "that's not my job." To genuinely want the project to succeed. Because when you care about something, you don't look at what your job title says. You look at what the project needs.
"When you care about something, you don't look at what your job title says. You look at what the project needs."
I don't have one single way to solve problems
But some things are always present. With real examples.
Understand before doing
ElectroPower came asking for "a website." If I had just done what they said without asking, I would have delivered a generic site no one would use. By listening, I understood that their entire business ran through WhatsApp. The website didn't replace the channel. It fed it.
Explain simply
The PATAgenda client is a teacher, not a programmer. The system models legal concepts from the Ministry of Education. If she didn't understand what she was looking at, the project would fail. That's why every screen and every term is designed for someone with no technical background.
Avoid unnecessary complexity
MyVisor is a Markdown reader. I could have used React, Next.js and a database. But Vanilla JS, Vite and the File System Access API were enough. Not everything needs a giant stack. Sometimes the best solution is the simplest one that solves the problem well.
I start by understanding, not building
I propose what makes sense, not the biggest thing. I advance in chunks, validate with something real, and improve on it. I work closely: I explain what we're doing, why, and how far to go. No jargon, no runarounds. And if something doesn't convince, we talk it through and find another way. I'm not interested in imposing solutions.
People don't hire me for writing fast. They hire me for understanding the problem before touching the keyboard. For choosing the right tool for each case. And for building interfaces people understand without a manual.
I'm not interested in talking in complicated terms. If an idea can't be explained simply, it probably hasn't been understood well. I try to make sure anyone can understand what I'm proposing, regardless of whether they're technical or not. Because building something no one understands is useless.