OM
EN ES

About

Full-stack dev, architect of design systems.

I build design systems, CMS-driven frontends, and durable UI architecture. Most of that work lives in private enterprise repos — this site translates it into hireable, IP-safe proof.

  • Remote · LATAM
  • 10+ years
  • Full stack developer

Osvaldo Morgan

Design Systems and enterprise frontends across Angular, React, and CMS — 10+ years.

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

Multi-framework Design System

Angular · React · Tokens

Open case
Atomic Design Atoms → Molecules → Organisms

Situation

Enterprise product surfaces shared branding across Angular applications—and a React viability check—while tokens and components risked drifting when each consumer evolved them alone.

Task

Establish a shared design-system foundation: semantic tokens, composition rules, and versioned packages that teams could adopt without locking every product to a single UI runtime.

Action

Kept the core to tokens, composition rules, and primitives; left business widgets outside the library. Generated semantic tokens from a JSON config through a build pipeline, shipped versioned packages with review, changelog, and deprecation discipline, and documented usage via in-library demos plus Storybook.

Result

Angular apps could migrate onto v3 module by module instead of in a big bang; a short React PoC validated cross-framework consumption without forcing full parity.

02

Schema-driven forms and state isolation

Forms · State · Delivery

Open case
Composition Field atoms → Form molecule

Situation

Across different client apps and CMS hosts, teams kept rebuilding similar form flows with bespoke validation and host shells that learned about every keystroke—slow to deliver and expensive to change.

Task

Apply a consistent layering mindset—schema, engine-or-state, and field UI—chosen per product or CMS, so form lifecycle stayed local and host-specific concerns stayed at the edge.

Action

On CMS surfaces, favored a stable form schema plus host adapters. On product apps, used a contract or typed-builder schema with a thin field UI. Reused patterns (conditional visibility, async validation, submit pipeline, dumb shells) only where that host needed them—not all at once in one app.

Result

Form-heavy work assembled faster when reuse justified a schema; tiny or hyper-custom forms stayed hand-built. Re-render noise dropped because shells stopped subscribing to every keystroke.

03

Multi-CMS frontend contracts

Sanity · HubSpot · Drupal · Shopify

Open case
Adapters Source atoms → UI organism

Situation

Content and commerce experiences spanned Sanity, HubSpot CMS, Drupal, and Shopify. Each integration pushed its own shapes into the UI, which made cross-surface features expensive and brittle—especially once catalog, cart, checkout, and payments entered the picture.

Task

Define stable frontend contracts—data shapes, errors, and schema-vs-UI ownership—so CMS differences stayed at an adapter edge, with a separate commerce contract for catalog, cart, checkout, and payment flows.

Action

Normalized host payloads before presentational layers. Kept ownership explicit: who changes schemas versus who consumes UI. Applied the model across Shopify (smart cart, Stripe-adapted checkout UI), Sanity (reusable page components), Drupal (module boundaries), and HubSpot (CMS surface and UI fixes)—without leaking CMS APIs into feature components.

Result

Engineers could reason about one contract model while still supporting multiple CMS backends. Integrations became swappable at the adapter layer rather than rewriting feature UI.

Open source

A library, and something real built with it.

  1. Library · on npm

    tokens-to-cssv1.1.0

    A Node library that compiles a design-tokens JSON file into a CSS custom-properties stylesheet.

    Design tokens are the contract; CSS custom properties are what a browser can actually use. This turns one into the other as a build step, so the stylesheet is generated from the token file instead of being kept in sync with it by hand. Published on npm under MIT.

    • On npm as tokens-to-css, MIT licensed
    • No runtime dependencies; Node 22.12 or newer
    • Consumed from the registry by plinth — installed, not vendored
    • Node
    • TypeScript
    • npm
    • Design Tokens
    SourceView on npm

  2. Showcase · deployed

    plinth

    A design system that consumes tokens-to-css from the registry like any other dependency.

    Eight components across three atomic levels, documented in Storybook and redeployed on every push to main. It exists to put the converter under load: every value a component paints resolves back to a token, so the token file stays the only place a colour or a size is written down.

    • 145 custom properties in three tiers — 68 primitive, 77 semantic and component
    • The tier hops survive compilation: --color-accent: var(--primitive-indigo-600) → #4f46e5
    • No component contains a literal colour, size, duration or font
    • 66 Storybook entries across 10 documentation pages
    • React 19
    • Vite 8
    • TypeScript 7
    • Storybook 10
    SourceOpen StorybookToken docs

Assistant

Questions the case studies did not answer?

There is an assistant that answers from this same documentation — the case studies above, the open-source projects and their architecture notes. It only knows what is written there, and it says so when something is missing.

Ask my assistant

Contact

Let’s talk about the next build.

Prefer a direct line. Email or WhatsApp — same day when I’m online.

Email WhatsApp Resume