Go back home

I am a full-stack web developer with a multidisciplinary background in engineering, design and digital product work, shaped by experience in international environments.

I studied Industrial Design and Product Development Engineering at the Universidad Politécnica de Madrid, where projects rarely had one obvious answer. You had to understand the problem, work within technical and practical constraints, consider the people who would use the solution, and justify the decisions you made along the way.

That taught me something I still value today. A good solution works and makes sense in its context.

From product design to web development

After university, my work moved across design, branding, multimedia creation, digital communication and project coordination.

These experiences strengthened my attention to detail, communication and stakeholder collaboration. They also taught me to consider both user needs and the wider requirements of a project.

I enjoyed thinking about interfaces and how people interacted with products, but I became increasingly curious about what happened behind the interface. I wanted to understand how the product itself was built, not only how it looked or how users moved through it.

That curiosity is what pushed me toward web development.

Once I started programming, the transition felt more familiar than I expected. Many of the habits were already part of my work, including breaking large problems into smaller ones, defining requirements, comparing approaches, working within constraints and iterating when the first solution was not good enough.

The medium changed, but the way of thinking did not.

How I approach development

I try to understand how each task fits into the wider product.

When I implement a feature, I consider its place in the user flow. When I design an API or structure a project, I think about how another developer will understand and maintain it. If a solution works but adds unnecessary complexity, I look for a simpler approach.

That is why I value planning and documentation. In collaborative projects, defining expected behavior, responsibilities, flows and decisions before coding makes implementation easier and reduces misunderstandings.

I don’t see documentation as separate from development. When it is useful, it becomes part of the engineering process.

My design background also keeps the user in view. I care whether a feature is technically correct, understandable, useful and consistent with the rest of the product.

What I am learning

My practical experience is currently focused on full-stack web development, using JavaScript, React, Python, Flask, REST APIs, PostgreSQL, HTML, CSS and Git/GitHub across frontend and backend projects.

Through personal and collaborative projects, I have been building applications involving frontend interfaces, backend services, database models, authentication flows, API integrations and technical documentation. As I build, I am becoming more interested in the engineering behind those applications, including system structure, API and service interactions, data modeling, maintainability, testing and collaboration around a shared codebase.

I want to answer more than “How do I implement this?” I also ask “Why should it work this way?”, “What does this decision affect?” and “Will it still make sense as the project grows?”

Where I am heading

I want to become a stronger web developer while gradually taking on broader software engineering responsibilities and contributing to real products.

I am especially interested in collaborative, international and engineering-focused environments where I can work with experienced developers, participate in code reviews and technical discussions, learn how larger systems are built and take increasing ownership of my work.

I bring a growing technical skill set and a background that has taught me to think in systems, consider the user, communicate decisions and approach problems with structure.

Those are the foundations I want to keep building on.