App builders like Lovable and Bolt get you a running application from a description, which is a genuinely different offer from a component or a template. The application has routes, a database, auth and deployment, and getting to that point by hand is days.
What they do not get you is a design that is yours, and the moment that starts to matter is usually the moment the product stops being a prototype.
What they are for
Validating a shape. Something clickable in an afternoon, in front of a real person, is worth more than a specification.
Internal tools. A dashboard three people use does not need a design system, and every hour spent on one is wasted.
A starting point with the plumbing done. Routing, auth wiring, a schema and a deploy is the unglamorous half of a new project.
Where it stops
The generated interface is generic by construction, which the not-generated guide explains: same palette, same layout rhythm, same copy that could be about anything. That is fine for a prototype and visible the moment the product has customers.
Three specific limits show up in the same order every time. The screens are near-misses of each other, because each was generated with its own spacing decisions. The states beyond the happy path are absent. And the components are new, so nothing is shared with anything you already own.
Bringing real components in
These builders write ordinary React with Tailwind, which means the standard install path works inside them. Three practical steps.
Set the tokens first. Before replacing anything, put your palette into the project's CSS variables. Half of what reads as generated is the default colour set, and this is a five-minute change that lifts every screen at once. The themes collection is a starting point.
Replace the components that carry identity. The hero, the pricing section, the empty states, the primary button. Not everything: the parts a reader looks at.
Then normalise the rest. Radii, spacing, focus rings. Consistency across screens is what separates a product from a demo, and it is mostly a find-and-replace once the tokens exist.
When to leave and when to stay
Stay while the thing is a prototype, an internal tool, or a business where the interface is not the differentiator.
Leave when you are fighting the builder to make a change, when the generated code is hard to read for someone who has to maintain it, or when the design has become the product. At that point the honest move is to export the code and treat it as a codebase, with the checklist as the first pass over it.
The middle path most teams take: keep the builder for the internal surfaces and rebuild the customer-facing ones properly, which is the same split the startup guide describes from the other direction.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| App builders | A running app with routing, auth and deploy | A generic interface and code you did not shape |
| Templates | A coherent codebase you own from the first commit | You wire the backend yourself |
| Components | Replacing the parts that carry identity | You are assembling |
| 21st MCP | Doing that replacement from inside the editor | Installs need a membership |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue.
Frequently asked
- What are app builders good for?
- Validating a shape with something clickable in an afternoon, internal tools where a design system would be wasted effort, and getting the unglamorous half of a new project done: routing, auth wiring, a schema and a deploy. All three are days of work by hand.
- How do you make a generated app not look generated?
- Three steps in order. Put your palette into the project's CSS variables first, since the default colour set is half of the impression. Then replace the components that carry identity: hero, pricing, empty states, primary button. Then normalise radii, spacing and focus rings across screens.
- When should you move off an app builder?
- When you are fighting it to make a change, when the generated code is hard for a maintainer to read, or when the design has become the product. At that point export the code and treat it as a codebase, starting with a review pass over what is there.
- Can you install components inside a builder project?
- Usually yes, because these builders write ordinary React with Tailwind, so the standard shadcn install path works. The limiting factor is whether you can edit files directly rather than only through prompts.