Profondeurs du produit
Salut, je suis Joaquin Mellado
Ingénieur logiciel senior full-stack créant des produits fiables propulsés par l'IA avec React, TypeScript, Python et une infrastructure cloud.
Software Engineer orienté produit
Je connecte l'ingénierie logicielle, le jugement produit, le craft frontend et les workflows IA pratiques pour construire des choses que les gens peuvent comprendre, apprécier et utiliser.
Réalisations
Je documente l'architecture, les décisions, les compromis et les résultats derrière les produits que j'ai construits. Chaque étude de cas montrera des problèmes réels, du code réel et des résultats réels.
Un assistant de recherche alimenté par l'IA pour les investisseurs en dividendes, combinant des pipelines de données financières, l'analyse de risque multi-agents, le RAG sur les documents SEC et des simulations de recherche de portefeuille explicables avec des garde-fous de conformité.
Outil de recherche éducatif — pas un conseil financier.
Stack technique
Flux d'architecture
Pourquoi maintenant
L'IA facilite la génération d'interfaces, de fonctionnalités et de code. Cela rend le jugement plus précieux, pas moins. Le vrai avantage est de savoir ce qui devrait exister, ce qui devrait être supprimé, ce qui devrait être mesuré et où le produit échoue réellement.
L'IA peut accélérer la production, mais elle peut aussi multiplier les idées faibles, les flux flous et les interfaces oubliables.
La vitesse, la clarté, l'accessibilité et la fiabilité façonnent la confiance avant qu'une feuille de route ou une liste de fonctionnalités ne le fasse.
Les décisions techniques déterminent dans quelle mesure les équipes peuvent changer, apprendre et livrer en toute sécurité sans créer de traînée invisible.
Les équipes solides utilisent le comportement, la friction, la rétention et les retours pour guider ce qu'elles construisent ensuite.
Ce que j'ai vraiment appris
J'ai travaillé dans la banque, les plateformes frontend à grande échelle, les workflows de risque internes et un MVP de startup que j'ai fondé. Contextes différents, même leçon : la qualité logicielle compte quand elle aide les gens à progresser.
Taux d'erreur, LCP, abandons, flux lents, signaux de support et données d'observabilité en disent souvent plus qu'une démo léchée.
Adobe, Datadog et les métriques de plateforme ne sont pas que des tableaux de bord techniques. Ils peuvent montrer si un produit fonctionne réellement pour les gens.
Les microfrontends, les packages partagés et les limites modulaires aident seulement quand la propriété et les schémas de changement sont clairs.
Je suis toujours à la recherche d'opportunités pour démarrer, tester et apprendre des produits. C'est probablement le meilleur moment pour le faire.
Ce qui me préoccupe
Un bon logiciel est la base. La question la plus difficile est de savoir si le produit crée de la valeur, change le comportement, gagne la confiance et reste maintenable tout en allant vite.
Les gens se souviendront-ils de cette expérience ou est-ce juste une interface de plus ?
Résolvons-nous un problème douloureux ou livrons-nous simplement une activité visible ?
Que font, répètent, évitent ou abandonnent réellement les gens ?
L'IA améliore-t-elle le jugement et la vitesse, ou augmente-t-elle seulement le volume de production ?
Le produit semble-t-il rapide, clair, accessible et fiable ?
Allons-nous vite sans créer de traînée invisible pour l'équipe ?
Signaux que je recherche
Les gens reviennent parce que le produit résout quelque chose d'important.
L'expérience continue de produire de la valeur après la première visite.
La confusion, l'hésitation, les étapes répétées et les abandons deviennent des entrées de conception.
La vitesse devient partie intégrante de la confiance, de la conversion et de la qualité perçue.
L'équipe s'aligne autour de la valeur, pas des tableaux de bord de vanité.
Les compromis sont explicites, intentionnels et visibles avant de devenir une traînée.
Pièges que j'évite
Plus de fonctionnalités peuvent rendre le produit moins mémorable.
Des chiffres qui ont belle apparence peuvent cacher un faible apprentissage produit.
Une UI propre peut cacher des décisions coûteuses et des coûts de maintenance futurs.
Des boucles de rétroaction longues affaiblissent le jugement produit et la qualité de livraison.
Product OS
Je travaille de l'ambiguïté au comportement livré via une boucle simple : découvrir, façonner, construire, mesurer, itérer.
Voir comment je construisNotes de terrain
Les décisions frontend les plus fortes sont rarement uniquement techniques. Elles façonnent l'autonomie de l'équipe, la vitesse de livraison, le risque produit et le coût des changements futurs.
Compromis d'architecture
Dans les grands systèmes frontend, j'ai vu comment les choix d'architecture affectent la sécurité de livraison des équipes, leur indépendance de travail et le coût des changements produit. Les microfrontends, la module federation, les bibliothèques partagées et les monolithes modulaires ne sont pas des niveaux de maturité. Ce sont des compromis.
Plus d'autonomie pour les équipes, mais plus de complexité opérationnelle et d'intégration.
Composition flexible au runtime, mais débogage, versioning et propriété plus difficiles.
Plus de cohérence et de réutilisation, mais possibles goulots d'étranglement de release et couplage.
Livraison plus simple, mais nécessite des limites solides pour éviter une entropie lente.
La meilleure architecture est celle qui correspond au rythme de changement du produit, à la structure de l'équipe, au profil de risque et aux besoins d'apprentissage.
Les transferts, l'onboarding et la gestion de comptes m'ont appris que la fiabilité, la clarté et la performance sont des fonctionnalités produit, pas des détails techniques.
Construire BinnApp de l'idée au MVP m'a appris à réduire le périmètre, coordonner la découverte produit et prendre des décisions techniques sous incertitude.
Preuve de savoir-faire
Le jeu Signal n'est pas une décoration. C'est une petite métaphore de ma façon de construire : identifier les signaux précieux, éviter les pièges coûteux, avancer avec intention et débloquer de meilleures décisions.
Si c'est ainsi que je conçois une interaction de portfolio, imaginez comment j'aborde des flux produit réels.
Quand je peux aider
Je travaille mieux quand il y a quelque chose de réel à résoudre : quoi construire, quoi simplifier, ce qui casse et comment livrer sans cacher le coût futur.
Je peux aider à transformer l'ambiguïté en flux, décisions et comportement livré.
Je considère l'architecture, la performance, la clarté UX et la maintenabilité comme un seul et même problème.
Je tiens à livrer, mais aussi à retirer le travail qui n'aide pas les gens à progresser.
Travaillons ensemble
Si votre produit a besoin de décisions plus fines, d'une meilleure qualité frontend ou d'une exécution consciente de l'IA, parlons-en.