Why We Design Data Models Before Opening Bubble
Every Bubble rebuild traces back to one failure: the data model was designed on the fly instead of on paper. Three hours of architecture saves three weeks of refactoring. Here is our exact data modelling process and what a well-architected Bubble data model looks like.
The One Discipline That Separates Good Bubble Builds from Great Ones
Every Bubble SaaS rebuild we have ever been asked to do traces back to one original failure: the data model was designed on the fly instead of on paper. When you design as you build, you discover relationships you did not anticipate, create fields that should be Option Sets, model multi-tenancy incorrectly, and embed assumptions that make future features nearly impossible to add cleanly. Three hours of data architecture before opening Bubble saves three weeks of refactoring after fifty customers are using the app.
How We Design a Data Model in Four Steps
Define every noun in the system
Every person, object, event, and concept that the system needs to know about becomes a candidate data type. We list them all before deciding which are types and which are fields on another type. For a project management SaaS: User, Workspace, Membership, Project, Task, Comment, Attachment, Tag, Notification. Every noun, written down before Bubble is opened.
Map every relationship
For each type, we ask: does it belong to another type? Does it relate to another type? Does it have a list of another type? We draw the entity relationship diagram by hand. A Task belongs to a Project. A Project belongs to a Workspace. A Comment belongs to a Task and has an author who is a User. Relationships drawn on paper before fields are created in Bubble.
Assign fields and decide what is an Option Set
Every field on every type. For each field: what type is it? If it is a status, a category, a role name, or any other enumeration with a fixed set of values — it is an Option Set, not a text field and certainly not a data type. We assign each field its type and note which fields are denormalised counters that will be updated by workflows.
Design the privacy rules
Before creating any data type in Bubble, we write the privacy rule for it. Who can find this type? Who can view its fields? Who can edit it? Who can delete it? The answers come from the user role matrix we built in step one of every project. Privacy rules designed on paper are implemented correctly. Privacy rules improvised in Bubble are the source of security incidents.
The Characteristics of Well-Architected Bubble Data Models
Workspace field on every type
Every data type that belongs to a tenant has a workspace field of type Workspace. This is the foundation of multi-tenant isolation. Without it, privacy rules cannot correctly scope data, and searches cannot correctly filter by tenant.
Option Sets for all enumerations
No status field stores text strings like ‘active’ or ‘pending’. All fixed-value fields use Option Sets. No database query is needed to display a dropdown of statuses. The values are defined at the app level and cost zero database operations to read.
Denormalised counters on parent types
member_count on Workspace. task_count on Project. comment_count on Task. Every number displayed on a dashboard or used in a plan limit check is stored directly, not calculated at query time. Updated by workflows on every creation and deletion.
Soft delete on every type
Every type has is_deleted (yes/no) and deleted_at (date). No record is ever hard-deleted. Searches exclude is_deleted = yes. This single decision prevents data loss incidents and enables the restore workflow that saves relationships with clients.
Append-only audit types
AuditLog and similar compliance types have privacy rules that allow creation but not editing or deletion. The audit trail is architecturally immutable. Nobody — including the admin — can alter a past record.
Plan limits in data, not code
The Plan data type stores every limit: seat_limit, record_limit, api_call_limit. Workflow conditions read from the Plan record. When pricing changes, a data record is updated. No code is deployed. No workflow is rewritten.
Work With a Bubble Architect
Most developers build Bubble apps. We architect them. Data models designed for scale, multi-tenant security built from day one, Stripe billing that never fails, and workflows engineered for performance. This is what a Bubble Architect delivers.
