Nimble Self Serve

Nimble is the biggest frontend project I have worked on, and the one that demanded the most from me as an engineer.

The product problem is clear: traditional teams ship a new frontend for every business model or brand. Nimble takes the opposite path. One platform. One shared runtime. Multiple tenants expressed through configuration.

I owned the frontend architecture end to end. At the center is a tenant runtime that resolves an active tenant, applies theme tokens as CSS variables, gates domains behind feature flags, and composes each page from a pages map and a component registry. The same product components can power different brands because behavior comes from tenant props, not hardcoded forks.

On top of that runtime I designed the self-serve surface: a public onboarding wizard that walks a business through setup and produces a tenant recipe. An assembly engine turns that recipe into a full tenant configuration with the same shape as handwritten tenant files. A preview path keeps configuration and the generated application in sync while the business configures branding, features, layouts, and domain intent.

The platform already runs multiple eCommerce tenant variants from one codebase, with booking/services supported as a first-class domain pattern. Isolation happens at three levels: feature gates, page maps, and component config. That is what lets Nimble scale horizontally without cloning repositories.

This is not a marketing page with a few templates. It is a config-driven SaaS frontend system with documented contracts for tenant generation, component mapping, routing and layout rules, and validation. I collaborated with backend engineers on configuration contracts, preview generation, and the path toward provisioning.

There is no public demo yet because Nimble is still being finished for launch. I am including it because this is the project that best represents how I think: architecture first, reusable systems, and frontend platforms that can grow without rewriting themselves.