Overview
Buzzy apps are made from a small set of durable artifacts: brief, flows, data model, theme, blueprint, screens, functions, widgets, tests, and security settings. Once you understand how those pieces connect, the editor, Builder MCP, Buzzy AI, code widgets, APIs, and Custom MCP all become easier to reason about.
Use this section when you want the mental model for how a Buzzy app works, not just a list of features.
Workspace Map
The Buzzy Workspace left navigation is organized around the app lifecycle: understand the app, build the definition, configure extension points and access, then release and support it.
Dashboard
App-level entry point and workspace overview.
Operational home for the app.
Blueprint
High-level screen map, navigation model, screen families, and major app surfaces.
Design
Screen-level layout and binding work: views, forms, fields, actions, widgets, and responsive UI.
Data
Datatables, fields, relationships, sample data, row access, field access, and Private Data.
Theme
App-wide visual identity, tokens, typography, colors, radius, shadows, and design guidance.
Constants
Reusable configuration values and secrets used by functions and integrations.
MCP
Builder MCP for app creation/editing, and Custom MCP for exposing an existing app as governed tools.
Functions
Server-side logic for APIs, AI calls, webhooks, sensitive processing, and custom workflows.
Settings
App privacy, app settings, authentication posture, screen settings, and deployment-facing configuration.
Publish
Make the app available through its intended deployment or sharing path.
Security
Security Review for permissions, Private Data, API/MCP exposure, and sensitive-data risk.
This section focuses on the conceptual building blocks behind those nav items. Some operational pages live elsewhere in the docs, especially publishing, deployment, and support.
How a Buzzy App Hangs Together
At runtime, a Buzzy app is driven by structured data and screens.
The data model defines the datatables, fields, relationships, permissions, and Private Data rules. Screens render that model into a usable app: they show lists and detail pages, collect data through forms, filter records, navigate between screens, run actions, and call functions or widgets when standard components are not enough.
Think of it this way:
Extensions
What needs custom UI, server-side logic, external APIs, constants, widgets, or MCP?
Confidence
How do we test, debug, and review risk before release?
Data Model First
Most Buzzy apps start with datatables.
A datatable is a structured collection of rows, like Properties, Bookings, Guests, Care Plans, Tasks, Tickets, Invoices, or Products. Each datatable has fields. Fields can store values such as text, numbers, dates, locations, images, files, status selections, ratings, and relationships to other datatables.
Screens only work well when they are bound to the right datatables and fields. A list screen queries a datatable. A detail screen displays one row. A create screen inserts a row. An edit screen updates a row. A child table, such as Booking Payments, usually inherits context from its parent row.
Start with Buzzy Datamodel Overview when you are new to datatables.
What Screens Do
Screens are the functional surface of the app. A screen is not just a static page. It can contain:
Views that query rows from a datatable and render repeated cards, tables, lists, calendars, maps, or dashboards.
Forms that create, read, or edit rows.
Fields that render values from the active row or collect new values.
Filters that feed query settings into views.
Actions that navigate, submit, delete, update fields, run functions, or trigger agents.
Widgets for richer interaction, including native widgets, reusable widget patterns, and custom code widgets.
The blueprint defines the screen set and navigation intent. The real screens then implement that intent with data bindings, layouts, actions, and widgets. See Blueprint, Design & Screens.
Themes
Themes are the app-wide design system. A theme includes visual identity, brand settings, light/dark mode, typography, colors, borders, shadows, radius, and design guidance. Screens and widgets should inherit that theme so the app feels like one product rather than a collection of unrelated pages.
Use Themes when you need to understand how theme choices shape generated screens, custom widgets, and later refinements.
Organizations, Teams, and Security
Buzzy security is layered. The app can be public, unlisted, or private. Signed-in users can have app roles such as Admin, Author, or Audience. Datatables then add row-level rules, field-level rules, Viewers fields, Team Viewers fields, and Private Data controls.
Organizations and Teams fit into that model as access groups.
Organization
Often represents a tenant, customer, business unit, school, clinic, agency, or partner group. Useful for multi-tenant apps.
Team
A named group of users, often inside or alongside an organization, such as Legal Reviewers, Compliance Team, Care Coordinators, Account Managers, or Technicians.
Viewers field
Grants row access to specific users.
Team Viewers field
Grants row access to members of selected teams or organizations.
Field view/edit
Controls which visible-row fields each user or group can see or change.
Private Data
Masks, hides, encrypts, gates attachments, and audits sensitive field access.
The key rule: row access is the first server-side gate. Field access and Private Data apply after the user is allowed to see the row. UI visibility rules are useful for experience, but they are not the security boundary.
For the full model, see Security and Access Control, Private Data, and Security Review.
Toolkits, Cookbooks, and Widgets in AI Builds
Builder MCP and Buzzy AI do not have to invent every app from scratch.
Cookbooks provide reusable product knowledge: app archetypes, workflows, data-model conventions, security expectations, integrations, and screen guidance.
Toolkits provide reusable UI structure: screen shells, sections, grids, components, fragments, navigation, forms, dashboards, lists, and responsive layout patterns.
Widgets provide richer interaction patterns that can be reused or embedded into screens. Standard/native widgets cover common app interactions; code widgets support custom HTML/React behavior when needed. The widget editor is available at app.buzzy.buzz/editor/widgets.
In an AI-assisted build, cookbooks guide what should be built, toolkits guide how screens should be structured, and widgets extend what a screen can do.
See Toolkits, Cookbooks & Widgets, Code widget, and Buzzy Builder MCP.
Testing, Debugging, and Review
Once an app works, capture the important workflows as repeatable tests. Tests help you think through flows and logic, then keep checking the app after changes to data, screens, functions, widgets, permissions, or integrations.
Use:
Tests for repeatable smoke and regression checks.
In-App Debugging when a screen, binding, action, form, view, or filter does not behave as expected.
Security Review before exposing sensitive data, adding external APIs, enabling Custom MCP, or publishing to a wider audience.
Where to Go Next
New to data: start with Buzzy Datamodel Overview.
Building an app with AI: start with Buzzy Builder MCP.
Building screens: read Blueprint, Design & Screens.
Extending the app: read API and Extension Surfaces.
Debugging a broken screen: read In-App Debugging.
Last updated