Hi, I'm Joaquin Mellado
Senior Full-Stack Software Engineer building reliable AI-enabled products with React, TypeScript, Python and cloud infrastructure.
Product-minded Software Engineer
I connect software engineering, product judgment, frontend craft, and practical AI workflows to build things people can understand, trust, and use.
Selected Work
I'm preparing concise case studies about the architecture, decisions, tradeoffs, and results behind the products I've built. Each one will show real problems, real code, and real outcomes.
An AI-powered research assistant for dividend investors, combining financial data pipelines, multi-agent risk analysis, RAG over SEC filings, and explainable portfolio research simulations with compliance guardrails.
Educational research tool — not financial advice.
Tech stack
Architecture flow
Why now
AI makes it easier to generate interfaces, features, and code. That makes judgment more valuable, not less. The real advantage is knowing what should exist, what should be removed, what should be measured, and where the product is actually failing.
AI can accelerate production, but it can also multiply weak ideas, unclear flows, and forgettable interfaces.
Speed, clarity, accessibility, and reliability shape trust before a roadmap or feature list does.
Technical decisions decide how safely teams can change, learn, and ship without creating invisible drag.
Strong teams use behavior, friction, retention, and feedback to guide what they build next.
What I have actually learned
I have worked across banking, large-scale frontend platforms, internal risk workflows, and a startup MVP I founded. Different contexts, same lesson: software quality matters when it helps people make progress.
Error rate, LCP, drop-offs, slow flows, support signals, and observability data often say more than a polished demo.
Adobe, Datadog, and platform metrics are not only engineering dashboards. They can show whether a product is actually working for people.
Microfrontends, shared packages, and modular boundaries only help when ownership and change patterns are clear.
I am always looking for opportunities to start, test, and learn from products. It is probably the best moment we have had to do it.
What I care about
Good software is the baseline. The harder question is whether the product creates value, changes behavior, earns trust, and stays maintainable while moving fast.
Will people remember this experience, or is it just another interface?
Are we solving a painful problem or just shipping visible activity?
What are people actually doing, repeating, avoiding, or abandoning?
Is AI improving judgment and speed, or only increasing output volume?
Does the product feel fast, clear, accessible, and trustworthy?
Are we moving fast without creating invisible drag for the team?
Signals I hunt for
People come back because the product solves something that matters.
The experience keeps producing value after the first visit.
Confusion, hesitation, repeated steps, and drop-offs become design input.
Speed becomes part of trust, conversion, and perceived quality.
The team aligns around value, not vanity dashboards.
Tradeoffs are explicit, intentional, and visible before they become drag.
Traps I avoid
More features can make the product less memorable.
Numbers that look good can still hide weak product learning.
A clean UI can hide expensive decisions and future maintenance cost.
Long feedback loops weaken product judgment and delivery quality.
Product OS
I work from ambiguity to shipped behavior through a simple loop: discover, shape, build, measure, iterate.
See how I buildField notes
The strongest frontend decisions are rarely just technical. They shape team autonomy, delivery speed, product risk, and the cost of future change.
Architecture tradeoffs
In large frontend systems, I have seen architecture choices affect how safely teams ship, how independently they can work, and how expensive product changes become. Microfrontends, module federation, shared libraries, and modular monoliths are not maturity levels. They are tradeoffs.
More team autonomy, but more operational and integration complexity.
Flexible runtime composition, but harder debugging, versioning, and ownership.
Better consistency and reuse, but possible release bottlenecks and coupling.
Simpler delivery, but it needs strong boundaries to avoid slow entropy.
The best architecture is the one that matches the product's rate of change, team structure, risk profile, and learning needs.
Transfers, onboarding, and account management taught me that reliability, clarity, and performance are product features, not engineering details.
Building BinnApp from idea to MVP taught me to reduce scope, coordinate product discovery, and make technical decisions under uncertainty.
Proof of craft
The signal game is not decoration. It is a small metaphor for how I build: identify valuable signals, avoid expensive traps, move with intent, and unlock better decisions.
If this is how I design a portfolio interaction, imagine how I approach real product flows.
When I can help
I work best when there is something real to figure out: what to build, what to simplify, what is breaking, and how to ship without hiding future cost.
I can help turn ambiguity into flows, decisions, and shipped behavior.
I look at architecture, performance, UX clarity, and maintainability as part of the same problem.
I care about shipping, but also about removing work that does not help people make progress.
Work with me
If your product needs sharper decisions, stronger frontend quality, or AI-aware execution, let's talk.