ABOUT FABRK

[THE ORIGIN]

FABRK started as a production boilerplate called fabrk.dev — a Next.js starter that I built and refined over years of shipping real SaaS products. Every time I started a new project, I'd pull in the same patterns: auth flows, payment integrations, dashboard shells, data tables, theme systems, AI tooling. The boilerplate grew into something genuinely useful.

It wasn't a framework. It wasn't a library. It was a living codebase that I kept copying, tweaking, and deploying. 109+ components, 18 themes, full auth with MFA, Stripe and Polar payment adapters, AI cost tracking, security hardening — all battle-tested in production.

[THE EXTRACTION]

Copying a boilerplate works until it doesn't. Bug fixes in one project didn't propagate to others. Improvements were siloed. I was maintaining the same code in multiple places — the exact problem a framework solves.

So I started extracting. Components became @fabrk/components. Auth became @fabrk/auth. Payments, email, storage, security — each concern got its own package with a clean interface. The design system with its 18 themes became @fabrk/design-system. The config system used Zod for type-safe validation across 12 sections.

Every external service went behind an adapter interface. Stripe, Polar, Lemon Squeezy — same API. S3, R2, local filesystem — same API. Every data store got an in-memory default so you could run the whole stack with zero external accounts. The monorepo took shape: 13 packages, each with a focused responsibility.

[THE PIVOT]

I was building a full-stack framework layer on top of all this — routing, SSR, Cloudflare Workers deployment, the works. A Vite-based runtime that would tie everything together. I was deep into it when Cloudflare released vinext.

Vinext did almost exactly what I was building for the runtime and server layer. SSR on Workers. Vite-based. MIT licensed. Built by a team with more resources dedicated to that specific problem.

I had a choice: compete with Cloudflare on runtime infrastructure, or accept that the runtime layer wasn't where my unique value lived. My value was everything else — the components, the themes, the auth, the payments, the AI toolkit, the security hardening, the design system.

So I pivoted. FABRK became a layer on top of vinext. Use their runtime. Keep all the batteries. The result: fabrk = vinext (runtime) + batteries (everything else).

[WHAT FABRK IS TODAY]

FABRK Framework is 13 packages. 109+ components. 18 themes. Auth with MFA. Three payment providers. AI cost tracking and streaming. Email templates. File storage. Security middleware. A CLI that scaffolds production-ready apps in seconds.

But the thing that makes it different isn't the feature count. It's who it's built for.

FABRK is the first UI framework designed specifically for AI coding agents. Claude Code, Cursor, GitHub Copilot, v0.dev — these tools are how apps get built now. When an AI agent can import a complete dashboard shell, a pre-built auth flow, or a payment integration instead of generating hundreds of lines from scratch, the quality goes up and the time goes down.

Every package includes AGENTS.md files documenting all components, props, and usage examples specifically for AI consumption. Every interface is designed to be discoverable by an LLM reading the type signatures. Every adapter pattern means an AI agent can wire up Stripe or S3 by changing one config line instead of writing integration code.

[WHO BUILT THIS]

I'm Jason Poindexter. I build SaaS products and the tools to build them faster. FABRK is the distillation of years of shipping — every pattern that worked, extracted and packaged so the next project starts further ahead.

github.com/jpoindexter