From a template

Use a template when the starting point is already close to the app you want. This lets the agent spend more time adapting structure, data, screens, and copy instead of starting from a blank app.

For general template concepts and examples, see Buzzy Templates.

Pick a template that is structurally similar to your idea, even if the topic is different. A short-stay rental app can be a good base for any browse, book, and message marketplace such as carers, tutors, cleaners, or trades.

Prefer a guided, step-by-step walkthrough that ends with a finished app? Follow the Tutorial: Build a Carer App from a Template.

How This Works

You act as the product owner. The agent acts as the builder.

In practice:

1. you connect and bootstrap the agent once

2. you give it the template app and the new app idea

3. the agent copies or references the template safely

4. it adapts the app in stages

5. it pauses for approval at important milestones

6. you keep refining by asking for specific changes

If you have not connected and bootstrapped your agent yet, start with Getting Started with Builder MCP.

Recommended Maker Workflow

1. Choose the closest template.

2. Give the agent the template editor URL or app ID.

3. Describe the new app and what is different from the template.

4. Answer any high-impact questions before the agent adapts artifacts.

5. Review each stage as it is built.

6. Open the live app and test the main journey.

7. Refine with focused follow-up requests.

Example:

I want to create an app for booking carers for clients. Use this app as the starting template: [template editor URL]. It is similar to short-stay booking, but client profiles include private support information.

What to Tell the Agent

Be explicit about what should stay from the template and what should change. The most important differences are usually:

• user roles

• what each user can see or edit

• private or sensitive data

• the core journey

• words that should never remain from the source template

• fields, filters, and booking or transaction rules

Useful prompt shape:

Connect to Buzzy MCP, bootstrap this repo, and start from the [template name] template. Before making changes, inspect the template app and summarize its current data model, core screens, and flows. Then make a plan to adapt it for [target product/use case].

Questions to Expect

The agent may ask a few setup questions before adapting the template. These should be high-impact questions, not a long interview.

For example:

• who manages each profile or booking?

• when can one role see another role's private details?

• how sensitive is the data?

• what source-template concepts map to the new app concepts?

• what source features should be removed entirely?

Answer in plain language. These decisions shape the data model, permissions, and screens.

Review Gates

Template-based builds still need the same review gates as new apps:

1. Brief: check that it describes the new app, not the template.

2. Flows: check that the user journeys match the new domain.

3. Data model: check fields, relationships, privacy, and ownership.

4. Theme: check whether the app feels right for the new audience.

5. Blueprint: check the screen list, navigation, and public/private posture.

6. Screens and sample data: check for realistic content and no leftover template wording.

Do not skip verification just because the starting point is a template. Templates speed up the first draft, but the agent should still prove the adapted app works for your specific use case.

Template-Specific Builder Rules

For technical Builder MCP work, template adaptation should be artifact-aware and careful:

• use the source template as protected reference material; Buzzy guides, skills, and app locks prevent editing the original template

• create a separate target app before adapting anything

• write a concept map before changing artifacts, for example Property -> Carer Profile or Host -> Carer

• adapt artifacts in order: brief, flows, data model, theme, blueprint, screens

• after each major push, re-read the persisted artifact and verify it

• scan for source-domain residue before moving on

• avoid regenerating a whole template artifact unless that is explicitly the goal

The core discipline is:

edit locally -> save or push -> re-read from Buzzy -> verify -> then continue

Screen and Data Gotchas

Template adaptation can fail in subtle ways if source-specific details leak into the new app.

Watch for:

• reused source IDs in copied data-model or screen artifacts

• stale source words in labels, sample data, filters, and helper text

• source-scoped tokens or signed URLs

• image assets that still show the old domain

• code-widget changes that accidentally rename JavaScript identifiers

• detail-screen widgets that show the first row instead of the current record

For sensitive apps, be precise about privacy. Mark sensitive fields as sensitive, set who can view them, and verify public, signed-in, and denied-user states where relevant.

Useful Follow-Up Requests

After the template-based app exists, keep changes specific:

• Give the app a visual refresh, but keep it appropriate for [audience].

• Remove any leftover [source template] wording from screens and sample data.

• Hide the exact address publicly and show only the suburb or general area.

• Replace the gallery with a simple image field on the detail screen.

• Add a richer search for location, date, and category.

• Open the live app, test the main booking path, and summarize any issues before changing anything.

Screenshots are useful for visual feedback. If something looks wrong, paste the screenshot and describe the specific outcome you want.