> For the complete documentation index, see [llms.txt](https://docs.buzzy.buzz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buzzy.buzz/the-building-blocks/mcp/buzzy-builder-mcp/from-a-template.md). # 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](/working-with-buzzy/buzzy-app-examples/buzzy-templates.md). {% hint style="info" %} 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. {% endhint %} {% hint style="success" %} Prefer a guided, step-by-step walkthrough that ends with a finished app? Follow the [Tutorial: Build a Carer App from a Template](/getting-started-with-buzzy/tutorial-carer-app-from-a-template.md). {% endhint %} ## 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](/the-building-blocks/mcp/buzzy-builder-mcp/getting-started.md). ## 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.buzzy.buzz/the-building-blocks/mcp/buzzy-builder-mcp/from-a-template.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.