Wuizard for indie developers: launch with a finished look

When you build alone, you are also the designer, and design time competes with everything else on the list. An AI coding agent closes a lot of that gap. It writes screens quickly, and they work. They also tend to look like every other AI-built app, and each new screen makes slightly different choices from the last.

Wuizard gives your agent a design system to follow, so the tenth screen matches the first without you policing every pull request. Here's how that fits an indie workflow, and when it isn't worth it.

Where the design time actually goes#

The first screen is rarely the problem. The time goes into everything after it:

• Keeping buttons, inputs, cards and spacing consistent as the app grows.
• The states nobody designs up front: loading, empty, error, success and confirm.
• Motion: a modal that opens the same way everywhere, page transitions that match, a toast that doesn't feel bolted on.
• The launch extras: a landing page, a pricing page, a changelog, an app icon, a 404.

Each one is small. Together they're the difference between an app that looks designed and one that looks generated.

Set it up once#

A sheet is your app's design system: foundations (colour, type, radius, spacing, shadows and a motion spring), slots with one chosen component each, and short rules. You can start one three ways: pick a starter vibe, paste a site you like into Extract, or describe your app to the sheet designer and let it choose colours, fonts, radius and motion for you.

Then fill the slots you'll use most from the library, connect your agent with the MCP setup guide, and ask it to summarise your sheet so you know it can see it. Most of the decisions you'd otherwise make screen by screen are now made once. The guide to designing a sheet covers the details.

Ship the product screens#

When your agent builds a screen, it calls get_sheet for the foundations and rules and get_slot for each component, and gets source with your values already in it. A few slots do a lot of work in a typical app:

• form.signin and input.text for the first thing every user sees.
• loader and feedback.empty for the states that are easy to forget. The loaders and skeletons topic shows the options running.
• feedback.toast, overlay.confirm and transition.modal for the moments that make an app feel responsive.
• micro.copy, micro.like and other small interactions from micro-interactions, if they suit your product.

Before you accept a screen, ask the agent to run check_ui. It lists anything outside your foundations, missing reduced-motion handling and hand-written versions of components that already have a slot.

Ship the launch pages#

Fill the section.* slots (hero, features, pricing, FAQ, call to action, footer and the rest) and your agent can ask for a whole page with get_page: a landing, pricing, about, contact, blog, changelog or 404 page, assembled from your sections in a sensible order. The sheet's Pages tab previews each one at desktop, tablet and phone widths.

Sections show neutral placeholder copy until your agent passes your real words, plans and numbers. Nothing on the page claims customers or prices you don't have.

Icons, images and small animations#

generate_media makes an app icon, a logo mark, an illustration, a photo, a background or a realistic UI screenshot in your sheet's colours, plus short animations, and saves them to the sheet. Your agent fetches the files with get_media, and the sheet designer can make them too. It's handy for a launch page or an App Store listing when you don't have an illustrator on call. The images and animations guide shows how to ask for them.

More than one product#

Indie developers rarely have just one project. Keep a sheet for each. Your agent can list them with list_sheets, and every tool takes a sheet name, so it never has to guess which product it's working on. Share links help here too: send one to a friend for feedback and they see a demo app built from the sheet, no account needed.

Keeping costs predictable#

Reading your sheet, its tokens and its components is free and unlimited. Only these are metered: extraction, framework translations, check_ui reviews, AI library search, sheet designer messages and generated media. The limits table lists what each plan includes, and your agent gets a clear message rather than a silent failure if you run out.

When to skip it#

• Throwaway prototypes. Don't build a system for something you'll delete next week.
• You enjoy designing and already have a system. If your own tokens and components live in the repo and your agent uses them without reminders, you may not need more.
• Little or no interface. A CLI, an API or a background service has nothing for a sheet to do.
• Offline work. Live sheet reads need a connection. The export works offline, but it's a snapshot.

If none of those apply, the quickest test is to make a sheet, connect the agent you already use and ask it for one real screen. If you also build by describing rather than coding, Wuizard for vibe-coders covers that side.