María Morán
Frontend engineer specializing in complex interfaces. I have built everything from editable org charts with thousands of nodes to AI-powered whiteboards — products where the frontend is not decoration, but the core of the product. I thrive at the intersection of architecture, product, and user experience.
- Typescript, Javascript
- CSS, HTML
- React
- Testing
Where I add the most value
-
High-complexity interfaces
I have experience building products where the frontend is the hard problem: visual editors, collaborative tools, AI integrations. I know how to structure this so it scales and stays maintainable.
-
Frontend architecture with judgment
I apply hexagonal architecture and system design principles to the frontend. I do not just write components: I think in layers, dependencies, and how the code will evolve.
-
Product engineering
I get involved beyond the ticket. I question requirements, propose solutions, and think about the user.
A special personal project
I like to code in my free time, and this is a project that means a lot to me.
-
Dyna
Web app that turns a planner design into a print-ready PDF in minutes, with the correct dates for any year. Born from a very specific problem I lived with for years as a creator of my own planners.
View project →
Selected articles
A piece of my knowledge base
-
BEM: the methodology that brings order to the chaos of your CSS classes
A practical introduction to BEM (Block, Element, Modifier), the CSS naming convention developed by Yandex. The article explains the logic behind the system, shows its syntax with real examples, and argues why adopting a naming convention has a direct impact on the maintainability and scalability of frontend projects.
Read2022
-
CSS Custom Properties: why native variables are more powerful than you think
An article that goes beyond the basic introduction to CSS Custom Properties. Rather than presenting them as a simple replacement for Sass variables, the article argues that they are a runtime communication mechanism — between CSS and JavaScript, between components and their context — and shows concrete patterns that a preprocessor cannot replicate.
Read2022
In public
Talks I have given in the community
How I work
I do not join a project just to implement tickets. I understand the product, understand the architecture, and design real solutions for real users.
-
1. Understand before touching
Before writing a single line, I analyze the existing architecture, dependencies, and where the real pain is. A good diagnosis avoids solutions that create new problems.
-
2. Design to scale
I organize code in layers with clear responsibilities, applying hexagonal architecture and system design principles. The goal is for the code to still be maintainable a year from now.
-
3. Test what matters
I write tests as part of the design, not as an afterthought. I care about strategic coverage: testing behavior, not implementation.
-
4. Think about the product
If something does not make sense for the user, I say so. I get involved beyond the ticket — I question requirements, propose alternatives, and consider the real impact of what I build.
Building something with complex interfaces? Let us talk.