Bootcamp
Module 14 — System operations: running software people rely on
Photo by Johnathan Kaufman on Unsplash
Nobody chooses a course for the operations module, and then it’s the module that saves them — usually within a month of their first real launch. Software that people rely on generates questions (“why didn’t my invoice send?”) that only operators can answer.
Operations is the craft of running live software: knowing what the system did (logs), changing what it holds (data operations), and adjusting how it behaves (settings) — all without breaking the thing people are using while they’re using it.
The curriculum
The diagnostic core: server logs and the scheduler log — the difference between “the app is broken” and “the 2 am job failed on record 3,117 with this error”. Students learnt to read them before touching anything, because acting without looking is how incidents become outages.
Data operations as a professional procedure: export data (backup before surgery), modify data, bulk actions, and worked scenarios — plus making content updates to a live app without collateral damage. The admin surface: limiting access, app and text language, plans, sub-apps for multi-tenant setups, and a clear-eyed lesson on plugins — third-party code is a dependency you’re marrying, so vet it like one. And the ethics-adjacent power tool: run as a user, for seeing exactly what they see when diagnosing their issue — with the responsibility that access implies.
Try it yourself
Open the logs of anything you run and reconstruct one recent hour: what jobs ran, what failed, what a user did. If you can’t tell, that’s the gap. Then do a fire drill: export a table, change one record via a bulk tool on a filter matching only that record, verify, restore. Rehearsing the procedure while calm is what makes it available when you’re not.
This skill in the AI era
AI can write code; it cannot own a production system — accountability doesn’t delegate. Logs, backups, safe bulk fixes, cautious plugin (now: dependency) judgement transfer directly to modern stacks, and they’re the difference between builders who ship and partners you can trust with live systems — the standard we hold on every system we operate for clients. Operational maturity is also half the pitch when rescuing an app whose original builder vanished at launch. The bigger story.
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.