Alternatives to starting your AI-built app from a template

A common way to start an AI-built app is to begin from a template: a starter kit, a dashboard theme or a landing page someone else designed. You get a polished first impression in minutes, and the agent has real code to imitate.

Templates are a reasonable choice, and for some projects the best one. But they have two weak spots that show up once you start adding your own screens. This page explains them and walks through five alternatives, with what each costs.

Why templates fall short over time#

• Your app looks like the template. Anyone else who started from the same template has the same hero, the same cards and the same footer. Re-skinning it properly is real work.
• New screens drift. A template covers the screens its author designed. When your agent builds a screen the template doesn't have, it imitates nearby code where it can and falls back on its own defaults where it can't.
• The system is implicit. The design decisions live inside the template's components rather than in a list of values and rules, so the agent has to infer them from code it may only partly read.
• Motion is whatever shipped. If the template animates a few things, the rest of your app won't match them, and the agent won't know the timing to copy.

None of that makes templates bad. It means a template is a good first screen, not a design system.

1. Keep the template, and extract its system#

If you like the template, make its implicit system explicit. Pull its colours, type, radii and spacing into a tokens file or CSS variables, write a short rules file that says which components to reuse, and tell the agent to build only from those.

This costs some of your time and nothing else. It works well when the template is close to what you want. It does less for motion and for the components the template never had.

2. A component library instead of a template#

Rather than a finished design, install a set of building blocks and theme them yourself. You lose the instant first impression and gain components that cover far more cases, with full control of the code. You still choose the look, tell the agent which component goes where, and add most of the motion yourself. Component libraries vs a design sheet compares this approach in detail.

3. Tokens and a rules file from scratch#

Skip the template and write the system down yourself: a tokens file with your colours, type scale, radii and spacing, and a project instructions file (such as CLAUDE.md or AGENTS.md) with the rules. It's free and it lasts across sessions.

The catch is the blank page. If you don't have a designer's eye, choosing a coherent palette and type pairing from nothing is the hard part, and the agent still writes every component itself.

4. Hire a designer for the foundations#

A designer can give you a brand, a real system and screens that fit your product rather than someone else's. For a product where identity matters, this is often the best money you'll spend, and nothing on this list replaces a good designer's judgement about your users.

The trade-offs are cost and time, and the handover: the designer's work still has to reach your agent in a form it can follow, which brings you back to one of the other options here.

5. Start from a design sheet#

A Wuizard sheet is a design system written for your agent: foundations (colour, type, radius, spacing, shadows and a motion spring), slots with one chosen component each, and short rules. There are three ways to start one that skip the blank page:

• A starter vibe. A ready-made sheet with colours, type, motion and a component in each starter slot. Browse the vibes, such as editorial or brutalist, to see how different they are.
• A site you love. Paste its URL into Extract and it reads the colours, type, radii and motion into a starting sheet. A screenshot works too, but gives only the colours. It copies values, never code.
• A description of your app. Tell the sheet designer what you're building and who it's for, and it sets the foundations and suggests components for your slots.

Then your agent connects over MCP and builds every screen from the sheet, including the ones a template would never have had. It fetches components with get_slot and whole pages with get_page, assembled from the sheet's page sections. check_ui flags anything that drifts. The trade-offs: the AI features are a paid service, a starter sheet needs your edits before it feels like yours, and the components are React first (translate_asset covers Vue, Svelte, SwiftUI and vanilla JS).

Side by side#

Which one to pick#

• Need a demo by Friday? A template is fine. Write down its values before you add screens.
• Identity matters and you have budget? Work with a designer, then give the agent their system.
• Want full control of every component? Use a component library and theme it.
• Want every new screen, motion included, to match without policing it? Start from a design sheet. The MCP setup guide shows how to connect your agent.