AtroUI vs shadcn/ui: production sections on the same ownership model

shadcn/ui and similar kits are excellent at one job: generate accessible primitives into your repo so you own every line. AtroUI uses the same CLI and ownership model, aimed at a different altitude: production sections and brand chrome that already look like a shipped product.

This is not a replacement pitch. It is a hiring decision: which catalog matches how you ship.

Same CLI, different catalog

You run the shadcn CLI either way. Components land in your monorepo. You customize freely. Updates are merges you control.

Choose a blank-slate kit when you are building a long-term internal design system from atoms. Choose AtroUI when you want heroes, who bands, footers, and CTAs with editable CONTENT on day one.

AtroUI: sections that ship

Add @atroui/home-hero, open the file, edit CONTENT. Brand defaults resolve through getBrand(). Tokens are dark-first.

Choose this when you want speed to a coherent dark UI, marketing + app chrome that share one system, and optional Host API tools that call your backends with BYOK.

Side-by-side differences

Distribution: both copy files into your repo via the CLI.

Altitude: atoms and patterns you assemble vs sections and chrome already composed.

Brand: you build chrome from scratch vs getBrand() + NEXT_PUBLIC_SITE_*.

Theme: often light-first or neutral vs dark-first catalog defaults.

AI / media tools: usually out of scope vs optional workspaces that expect your /api/*.

You can use both

Some teams keep shadcn-style primitives for domain forms and use AtroUI for marketing bands and site chrome. That is valid. Avoid two competing token sheets on the same page without a clear boundary.

Pick and install

Prefer a blank-slate kit if you want every primitive from scratch. Prefer AtroUI if you want a ready dark catalog at atroui.com.

Docs: Compare. Install: Installation. Registry: Registry. Positioning: What is AtroUI?.