> 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-ultimate-guide-for-vibe-coding-an-application-with-ai/building-examples/short-stay-template-adaptation.md).

# Short Stay to Care Connect

The Short Stay to Care Connect example shows why Builder MCP matters.

Instead of asking AI to generate a new standalone codebase from a blank prompt, Builder MCP can inspect and adapt an existing Buzzy app definition. The Buzzy runtime stays maintained by Buzzy; the durable artifact is the app definition: brief, flows, data model, theme, blueprint, screens, functions, widgets, and settings.

## Why Short Stay is a Strong Source Template

A short-stay rental marketplace already contains many patterns that other service marketplaces need:

* public search
* listing cards
* provider profiles
* availability
* booking or request flows
* pricing
* client and provider roles
* admin review
* support and policy screens
* role-based access

That structure can be adapted into another domain. In the public Buzzy case study, Short Stay becomes Care Connect, a care booking app.

## Semantic Mapping

| Short Stay concept     | Care Connect concept                   |
| ---------------------- | -------------------------------------- |
| Property listing       | Carer profile                          |
| Guest or rental client | Care client                            |
| Host                   | Carer or care provider                 |
| Nightly booking        | Hourly care booking                    |
| Rental availability    | Care availability windows              |
| Property search        | Provider, service, and location search |
| Platform admin         | Care operations admin                  |

This is not just a copy change. The domain semantics change. A care booking app has stronger privacy and governance requirements than a rental marketplace. Addresses, care needs, identity details, support information, and operational notes need more careful access design.

## Builder MCP Workflow

Use this workflow when adapting a template:

1. Export or inspect the source app.
2. Read the source brief, flows, data model, blueprint, theme, screens, functions, and widgets.
3. Write an adaptation plan that maps source concepts to target concepts.
4. Rewrite the target brief first.
5. Adapt flows to the new domain.
6. Adapt the data model, including privacy and permission decisions.
7. Adapt theme and blueprint.
8. Ensure screens from the blueprint.
9. Adapt screen content, bindings, navigation, and actions.
10. Generate sample data.
11. Run Release Tests on search, detail, request/booking, admin, and permission paths.
12. Run Security Review before sharing sensitive workflows.

## What to Review Carefully

* Domain terminology: every source-domain label should be adapted or removed.
* Data sensitivity: the target app may need Private Data, field-level access, and stricter row access.
* Booking logic: nightly stays and hourly care visits do not behave the same way.
* Location display: a public property address and a care provider's private address have different risk.
* Roles: host, guest, client, provider, carer, admin, and reviewer are not interchangeable.
* Custom code: code widgets and functions may contain source-domain assumptions.
* Tests: old test paths may still click through but prove the wrong business behavior.

## Related Reading

* [How We Turned a Short Stay Rental App into a Care Booking App with Buzzy Builder MCP](https://www.buzzy.buzz/post/short-stay-to-care-connect-buzzy-builder-mcp/)
* [Tutorial: Build a carer app from a template](/the-building-blocks/mcp/buzzy-builder-mcp/tutorial-carer-app-from-a-template.md)
* [Buzzy Builder MCP](/the-building-blocks/mcp/buzzy-builder-mcp.md)
* [Security Review](/the-building-blocks/security-review.md)
* [Release Tests](/the-building-blocks/release-tests.md)