OM
EN ES

Sobre mí

Full-stack dev, arquitecto de design systems.

Construyo design systems, frontends orientados a CMS y arquitectura UI duradera. Gran parte de ese trabajo vive en repos privados — este sitio lo traduce en prueba contratable y segura para IP.

  • Remoto · LATAM
  • 10+ años
  • Full stack developer

Osvaldo Morgan

Design Systems y frontends enterprise en Angular, React y CMS — más de 10 años.

  • Angular
  • React
  • TypeScript
  • Design Systems
  • Astro
  • Node
  • Shopify
  • Drupal
Email WhatsApp CV
Scroll
01

Sistema de diseño multi-framework

Angular · React · Tokens

Abrir caso
Atomic Design Atoms → Molecules → Organisms

Situación

Las superficies de producto compartían marca sobre todo en aplicaciones Angular—con un PoC corto en React—mientras tokens y componentes tendían a divergir si cada consumidor los evolucionaba por su cuenta.

Tarea

Establecer una base de design system: tokens semánticos, reglas de composición y packages versionados que los equipos pudieran adoptar sin atar cada producto a un único runtime de UI.

Acción

Dejé el núcleo en tokens, reglas de composición y primitivos; los widgets de negocio quedaron fuera de la library. Generé tokens semánticos desde un JSON de configuración vía pipeline de build, publiqué packages versionados con review, changelog y deprecations, y documenté el uso con demos en la library y Storybook.

Resultado

Las apps Angular pudieron migrar a la v3 módulo a módulo en lugar de un big bang; un PoC corto en React validó el consumo cross-framework sin forzar paridad total.

02

Formularios por schema y aislamiento de estado

Forms · State · Delivery

Abrir caso
Composition Field atoms → Form molecule

Situación

En distintas apps de cliente y hosts CMS, los equipos reconstruían flows de formularios parecidos con validación a medida y shells que se enteraban de cada keystroke—lentos de entregar y caros de cambiar.

Tarea

Aplicar un criterio de capas consistente—schema, engine-o-estado y field UI—elegido por producto o CMS, para que el lifecycle del form se quedara local y lo específico del host en el borde.

Acción

En superficies CMS, prioricé schema estable de form más adapters del host. En apps de producto, schema por contrato o builders tipados con field UI delgada. Reutilicé patterns (visibility, validación async, submit pipeline, shells tontos) solo donde ese host los necesitaba—no todos a la vez en una sola app.

Resultado

El trabajo con forms pesados avanzaba más rápido cuando el reuso justificaba un schema; los forms mínimos o hiper-custom se seguían armando a mano. Bajó el ruido de re-render porque los shells dejaron de suscribirse a cada keystroke.

03

Contratos frontend multi-CMS

Sanity · HubSpot · Drupal · Shopify

Abrir caso
Adapters Source atoms → UI organism

Situación

Las experiencias de contenido y comercio atravesaban Sanity, HubSpot CMS, Drupal y Shopify. Cada integración empujaba sus propias formas a la UI, lo que encarecía y fragilizaba el trabajo cross-surface—sobre todo cuando entraban catalog, cart, checkout y pagos.

Tarea

Definir contratos frontend estables—formas de datos, errores y ownership schema vs UI—para que las diferencias de CMS quedaran en un borde de adapter, con un commerce contract aparte para catalog, cart, checkout y pagos.

Acción

Normalicé payloads del host antes de las capas presentacionales. Mantuve ownership explícito: quién cambia schemas versus quién consume UI. Apliqué el modelo en Shopify (smart cart, form Stripe adaptada a la UI), Sanity (componentes reutilizables en pages), Drupal (boundaries de módulos) y HubSpot (CMS surface y UI fixes)—sin filtrar APIs de CMS a componentes de feature.

Resultado

Los ingenieros podían razonar sobre un modelo de contrato mientras soportaban múltiples backends CMS. Las integraciones se volvieron intercambiables en el adapter sin reescribir la UI de features.

Open source

Una librería, y algo real construido con ella.

  1. Librería · en npm

    tokens-to-cssv1.1.0

    Una librería Node que compila un JSON de design tokens en una hoja de estilos de custom properties CSS.

    Los design tokens son el contrato; las custom properties CSS son lo que el navegador sabe usar. Esto convierte uno en lo otro como paso de build, así la hoja de estilos se genera desde el archivo de tokens en vez de mantenerse sincronizada a mano. Publicada en npm bajo licencia MIT.

    • En npm como tokens-to-css, licencia MIT
    • Sin dependencias en runtime; Node 22.12 o superior
    • plinth la consume desde el registro — instalada, no copiada
    • Node
    • TypeScript
    • npm
    • Design Tokens
    CódigoVer en npm

  2. Showcase · desplegado

    plinth

    Un design system que consume tokens-to-css desde el registro como cualquier otra dependencia.

    Ocho componentes en tres niveles atómicos, documentados en Storybook y redesplegados en cada push a main. Existe para poner el conversor bajo carga: cada valor que pinta un componente resuelve de vuelta a un token, así el archivo de tokens sigue siendo el único sitio donde se escribe un color o un tamaño.

    • 145 custom properties en tres niveles — 68 primitivas, 77 semánticas y de componente
    • Los saltos entre niveles sobreviven a la compilación: --color-accent: var(--primitive-indigo-600) → #4f46e5
    • Ningún componente contiene un color, tamaño, duración o tipografía literal
    • 66 entradas de Storybook y 10 páginas de documentación
    • React 19
    • Vite 8
    • TypeScript 7
    • Storybook 10
    CódigoAbrir StorybookDoc de tokens

Asistente

¿Te quedaron preguntas que los case studies no responden?

Hay un asistente que responde a partir de esta misma documentación — los case studies de arriba, los proyectos open source y sus notas de arquitectura. Sólo sabe lo que está escrito ahí, y lo dice cuando algo falta.

Pregúntale a mi asistente

Contacto

Hablemos del próximo build.

Línea directa. Email o WhatsApp — respondo el mismo día cuando estoy en línea.

Email WhatsApp CV