Forge UI

Context

Why I built a UI kit instead of just writing about one

Most of my career has been spent writing and governing the rules that make interfaces consistent, banners, error states, button labels, the words a design system speaks. Forge UI started as a question: could I build the other half, the actual components those rules apply to, and ship something a small team could drop into a real product?

Forge is a free, MIT-licensed UI kit: two files, one script tag, no framework dependency, no build step. It works in Django, Rails, Laravel, Spring, or plain HTML. The goal wasn't to build another design system for a company that could already afford one. It was to prove that accessible, professional-grade UI shouldn't require an enterprise budget.

"Enterprise UI. No invoice required." Forge's landing page and its core promise.

What I built

A full component library, not a demo

Forge ships buttons, inputs, selects, toggles, badges, alerts, cards, and modals, each with a documented HTML API and full keyboard and screen-reader support. A small JavaScript layer handles behavior (button loading states, modal open/close, toggle state) without requiring a framework. It's published to npm and versioned like any real package.

Core Kit is the foundation; SCM, Finance, CRM, and HR modules layer on top using the same patterns.

Accessibility and theming

Accessible by default, not by request

One in four people lives with a disability. Accessibility is too often treated as an enterprise concern, something addressed when a procurement team requires it, which means small businesses building on a budget end up shipping software that excludes people by default, not on purpose, but by neglect. Every Forge component ships WCAG 2.1 AA compliant from day one: correct ARIA roles, keyboard navigation, focus management, and live-region announcements, not as an upgrade tier.

Theming works through CSS custom properties: override a handful of variables on :root and every component re-brands without touching component code. A set of surface utilities (forge-surface-dark, forge-surface-light, forge-surface-accent) guarantee accessible contrast automatically, so a team can restyle a whole section without manually checking contrast ratios.

Applied in practice

Built to prove it works, not just look good in isolation

A component library is only as credible as what you can build with it. I used Forge to build a full supply chain management (SCM) module, a data-dense dashboard with purchase orders, supplier tracking, and shipment status, and a standalone invoice generator app, to prove the kit holds up under real product complexity, not just button and card examples.

The SCM module: purchase orders, supplier cards, and status badges built entirely from Core Kit components.

A standalone invoice generator: form on one side, live document preview on the other.

Working with AI

Directing the build, not just writing about it

I built Forge using Claude Code. I set the architecture, the accessibility requirements, the component API, and the theming model, then worked with Claude Code to implement and iterate quickly across the kit, the SCM module, and the demo apps. That workflow is the same instinct behind the Agentic App Guidelines work in my Oracle case studies: knowing what rules and structure an AI tool needs to produce something reliable, and staying in the loop as the judgment behind the output rather than stepping back from it.

Outcomes

A shipped v1.0.0, not a prototype

Forge went from initial commit to a versioned, npm-published v1.0.0 release, with a dedicated SCM module and two working demo apps, over a focused, multi-day build.