Brand Kits

A brand kit is a saved set of design choices: your colors, your fonts, your logo, your voice. You set one up once, attach it to a project, and from then on every screen the agent builds uses those choices automatically. No more "actually, make the buttons a bit warmer" five prompts in.

Think of it like a style guide you hand to a designer. The designer takes care of every screen looking consistent with what you gave them. The agent does the same.

What lives in a brand kit

Each kit holds:

• Colors: primary, accent, background, and foreground. The four values that decide how every button, card, header and screen looks. Each one has a dark-mode counterpart too.
• Images: a primary logo used on splash screens and headers, an optional logo for dark backgrounds, and a brand mark - a square icon the agent shows wherever the app's identity appears in-app. (The installable home-screen icon is set separately, at export.)
• Fonts: heading and body, picked from a curated list of Google Fonts grouped into sans, serif and mono.
• Style: six dials - corner radius (sharp, rounded, pill), button style (filled, outlined, ghost, gradient), icon style (outline, filled, duotone), density (compact, comfortable, spacious), shadow (flat, soft, elevated) and border weight (hairline, standard, bold). The agent translates these into consistent component styling.
• Voice: a tone (friendly, professional, bold, or playful) plus an optional tagline and short description. Affects what the agent writes for empty states, error messages, onboarding and store copy.
• Splash screen settings: background color, and whether the logo sits centred or near the top.

You don't fill all of this out at once. The agent runs with what you've set; defaults fill the rest.

When to make one

You don't need a brand kit for your first project. The agent picks sensible defaults if you don't pin one.

Make a brand kit when:

• You're building something for your own brand and want to reuse it across projects (pin it to each one).
• You're building multiple projects that should look like they're from the same company.
• You want to stop re-prompting ("use a warmer palette", "use a serif font", "smaller corners") on every new project.
• You're handing off to a designer or developer and want a single source of truth they can edit.

Creating your first brand kit

Brand kits are a Pro and Business feature, and each plan allows a fixed number of them - the counter beside the page title tells you where you stand.

1. Go to Dashboard → Branding.
2. Click New brand kit (or Create brand kit if it's your first).
3. A modal asks for a name. Anything works. "My company," "Beach App," whatever.
4. The editor opens.

The editor has two halves:

• Left: a form with seven sections, grouped into three cards - Identity and Splash; Colors · Light mode, Colors · Dark mode, Typography and Style; and Voice. Edit anything.
• Right: a live preview - a phone mockup of a sample screen rendered with your choices, with a Light/Dark toggle. Updates in real time as you edit.

There's no Save button. Every change auto-saves after about half a second of inactivity. Under the kit's name you'll see "Saving…" while it's in flight and "Saved · just now" once it lands, plus a brief toast confirming it.

Picking colors

Four color slots. The two that matter most:

• Primary: your main brand color. Used on primary buttons, key icons, links, accent elements.
• Accent: a contrasting color for variety. Used sparingly on highlights, secondary CTAs, badges.

The other two:

• Background: the main app surface (usually a near-white in light mode, near-black in dark mode).
• Foreground: the main text color.

If you only know one color you care about, set it as the primary and leave the rest as the defaults. The agent will work with that.

Adding a logo

Upload via drag-drop or click. PNG, JPEG or SVG, up to 2 MB. Each slot previews the way it will actually be used: the primary logo on a light card, the dark logo on a dark one, and the brand mark at three icon sizes.

Tip: square-ish logos work best. Most app surfaces (icons, splash screens, headers) are roughly square or circular. A wide landscape logo will look fine on the splash but get awkward in tight spots.

Tone of voice

Pick one of four tones - Friendly, Professional, Bold, or Playful - and the agent writes every piece of UI copy to match it. Onboarding screens, empty states, error messages, button labels, push notifications, and any store copy it drafts for you.

• Friendly: warm and plain-spoken, like a helpful person rather than a system.
• Professional: precise and calm. Treats the user as competent, skips the exclamation points.
• Bold: short, confident, direct. Verbs first.
• Playful: light and human, with the occasional bit of wit.

The two text fields above it steer the same copy:

• Tagline - your splash line and App Store subtitle (80 characters).
• Short description - the App Store and social blurb (155 characters).

Leave both blank if you'd rather the agent write them from the app itself. Both steer what the agent writes; neither is published to a store on its own - you still fill in the real listing when you submit.

Light and dark colors

Every color slot has a dark-mode counterpart, and by default Appsanic derives it for you:

• Background and foreground are replaced, not converted: the dark background is Appsanic's own near-black and the dark text is its near-white, whatever you picked for light mode. Your light values don't carry across.
• Primary and accent are kept exactly as you set them if they're already readable on that near-black. If not, they get a single lightening step toward white - one step, so a very dark brand color comes out lighter but may still be hard to read.

Turn Auto-derive off on any row to set the dark value by hand - that's the fix when the derived color isn't the one you want.

The editor then checks the pairings a built app actually renders and flags any that fall below a readable contrast ratio: body text, buttons and the accent against the background in both light and dark mode, and the button label on your primary color. It's a warning, not a block: the agent treats your palette as the source of truth and will build exactly what you set.

The logo slot works the same way: upload a dark logo and the agent uses it wherever the app is in dark mode, falling back to your main logo if you don't.

State colors

Every app needs three more colors than a palette gives you: success for a saved confirmation, warning for something expiring, danger for a delete button. Appsanic derives all three from your palette - it starts at the colour people already read as "done / careful / stop", pulls it toward your primary so it belongs to your brand, then lightens or darkens it until it's legible on that theme's background. A kit with four colors gets a coherent seven, and the same three values go to the agent that builds your app, so generated screens stop reaching for stock green and red.

Turn Auto-derive off on any of them when your brand has a specific color it has to use - a trademarked red, a green from your existing product. An override is used exactly as written and is not adjusted for contrast, on the assumption that you mean it. Check the contrast report above the section if you're unsure.

Both themes are editable independently. A dark override falls back to your light one, and a light one falls back to the derivation - so you only set what you actually care about.

Marking a default

If you have multiple kits, you can mark one as your default. This is just a label: it sorts the kit to the top of your list and protects it from accidental deletion (you'll be asked to pick a new default before removing it). It does not apply the kit automatically - a brand is only ever used on a project when you pick it there. New projects start with no brand until you choose one. Use Set as default in the editor header or the kit's menu; one kit at a time holds it, and promoting another moves the label across.

Attaching a kit to a project

Inside a project, there's a small "Sanic AI brand" pill above the composer (the chat input) - it reads "No brand selected" until you pick one. Click it to:

• Pick a kit for this project.
• Switch to a different kit.
• Rename the active kit inline.
• Open the full kit editor, or the whole Branding page, in a new tab.
• Build without a brand (clears the pin so the agent uses its defaults).

Changing the kit applies to all future agent work in that project. It doesn't retroactively re-style screens that already exist - for those, use Restyle this app to the brand in the same pill.

Managing kits

From Dashboard → Branding, you can see all your kits. Each card's menu offers:

• Edit - opens the kit in the editor.
• Duplicate an existing kit as a starting point for a new one.
• Set as default: only one default at a time.
• Delete a kit. Any project pinned to it drops back to "no brand," and the kit's uploaded images go with it - so an app that still references those images will fail to build until you remove the references.

Renaming isn't in that menu: rename a kit from the pencil beside its name in the editor, or inline from the in-builder pill.

Everyone on the account sees the same kits. Owners, admins and members can change them; viewers get a read-only preview - the editor opens, but every control is locked.

Tips that pay off

• Make your first kit before you build your second project. That's the moment you'll start to feel friction without one.
• Don't over-fill the form. A primary color, a logo, and a tone sentence is enough for the agent to keep everything consistent.
• Iterate. Open the kit, change the primary color, watch the preview, decide. Way faster than re-prompting "make the buttons darker" inside a project.

What it doesn't do

• It doesn't change the App Store screenshots or listing. Those are separate. See App Store and Play Store.
• It doesn't yield to a contrary prompt. A pinned kit is the source of truth for design: ask for _"a bright yellow CTA"_ while a kit is pinned and the agent uses the brand's colour instead, and tells you it did. Change the kit if you want a different look - that's the point of pinning one.
• It doesn't restyle old screens on its own. Screens built before you pinned the kit stay as they are. Restyle this app to the brand in the brand pill writes the request into your composer for you - read it, then press send yourself, because the run costs credits.

Under the hood (for engineers)

• Stored in brand_kits table, one row per kit, scoped to an account via RLS. Every login in that account sees the same kits, and account boundaries keep kits isolated.
• The pinned kit on a project is stored as projects.brand_kit_id, a foreign key that nulls itself if the kit is deleted.
• Every plan and build run appends the active kit as its own system block, after the cached base prompt: colors (light and derived dark), the @expo-google-fonts packages for the two families, each style dial translated into concrete React Native values, the tone, and the asset paths.
• Images land in a private Supabase Storage bucket (logo_url, logo_dark_url, app_icon_url on the kit row). Generated apps reference them through the reserved assets/appsanic/brand/... path; the browser preview, Expo Go and a real build each resolve that path to the bytes the slot currently holds, so replacing a logo updates every app that uses it.
• src/stores/brand-kits-store.ts owns all writes and is the client's single source of truth for the account's kits; the editor debounces field changes 600ms before handing them over.

Next

Read Writing Prompts. Even with a brand kit pinned, well-written prompts still matter for the screens themselves.