Bootcamp
Module 10 — Data security: privacy rules as a first-class discipline
Every experienced builder has a moment of cold sweat about data security — usually after shipping. Module 10 existed so students would have it before, in a classroom, where it’s cheap.
The first principle of application security: the interface is a courtesy, not a boundary. Access control is real only when it’s enforced at the data layer, for every request, regardless of what any screen shows.
The curriculum
Principles first — who should see what, stated in business terms. Then app configuration, privacy rule expressions (the conditions defining “this user may see this record”), and permissions — the find/view/modify distinctions that make rules precise. Use cases grounded it, documentation made it reviewable, and a set of exercises made it muscle memory. The planning method was the quiet star: a privacy rule table — roles × data types, with each cell’s permissions written down before any rule is built. Security designed on paper, then implemented.
The practical secured the Module 9 CRM properly: database updates, a create team member flow, and the flagship exercise — restricting deals to their assigned user, so the account structure, data model and privacy rules all click together into “you see your deals, your teammate sees theirs”.
Try it yourself
Draw the permissions table for your app: every role, every data type, and in each cell S/V/E for search, view, edit. Two uncomfortable questions will surface within minutes — usually about ex-employees and about which fields of “public” records are actually public. Answering them on paper is the whole discipline.
This skill in the AI era
AI-generated apps are conspicuously good at features and conspicuously silent about access control — nobody prompts for what they haven’t learnt to think about. The permissions table transfers verbatim to modern stacks (as row-level security policies and middleware), and it’s what we audit first in any app rescue. A builder who thinks in privacy rules directs Claude Code toward software that’s safe by design, not by luck. The skills that carried over — this one leads the list.
If this sparked something, let's talk.
No pitch, no pressure — just a conversation about what you're working on.
Let's talkRelated posts
Bootcamp
A simple approach to data modelling
A four-step method for designing a database schema: identify entities, map relationships, choose fields. Taught through the CRM data model built in Bubble.
Bootcamp
Module 5 — Application architecture: pages, states and reusable pieces
Single-page vs multi-page apps, URL parameters, custom states, reusable elements — and a big practical building a main template with an expanding navigation drawer.
Bootcamp
API calls as actions vs data (and the planning checklist)
When to use Bubble API calls as actions versus data sources, a one-to-many auth pattern, and the planning checklist that keeps integrations from failing silently.