Bootcamp
Module 15 — Speed and scale: performance as a design habit
Photo by Bill Jelen on Unsplash
Module 15 reframed performance from a tuning exercise you do at the end to a set of habits you hold all the way through. Slow apps aren’t unlucky; they’re designed slow, one careless search at a time.
The performance mindset: every piece of data fetched, every workflow step, every element rendered has a cost. Fast apps aren’t optimised into existence — they’re built by people who feel those costs as they build.
The curriculum
What is speed and scale separated the two (fast for one user; still standing for a thousand), then the economics: usage patterns — scale problems are shaped like your users’ behaviour, the Monday 9 am spike, the month-end report — workload units, pricing plans, and measurement, because optimising without measuring is redecorating in the dark. Logs turned diagnosis into evidence.
Then the habits, swept through every layer students had built across fourteen modules: design and styles (what renders, when), data modelling for performance — the Module 9 decisions cast in a new light: a normalised model with lean fields is also the fast model — workflows (client vs server, deferred work), settings, and plugins (every convenience is somebody’s code running on your pages). The practical challenge capped it: take a working feature, measure it, make it measurably faster.
Try it yourself
Pick your app’s slowest screen and audit it in three questions: What data does this fetch, and how much does it show? What runs on load that could run later? What repeats that could be constrained? Fix only what measurement confirms. The habit of asking beats any specific trick — tricks expire, the questions don’t.
This skill in the AI era
We live this one publicly: our own site scores 98–99 on Lighthouse because the audit found a blocking script and we removed it — measure, find, fix, exactly as taught. AI writes performant code when directed by someone who knows what to ask for (lean queries, lazy loading, server-side work) and how to verify it. Performance thinking also powers our SEO work — speed is a ranking factor — and every build we ship. The practice, then and now.
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.