There’s a particular kind of founder I keep meeting lately. They have a Bubble app. It works, mostly. It has real users, or is about to. And somewhere along the way it grew past the point where anyone can hold the whole thing in their head.
The developer who built it has moved on, or is a contractor who answers every third email, or is the founder themselves, two years and several hundred workflows ago. The documentation is a Figma file, a Jira board, a Confluence space that was accurate once, and a lot of things that only ever lived in a Loom video.
So every change is a gamble. Touch one workflow and something three pages away stops working. Nobody’s sure which privacy rules actually exist. There’s a suspicion that a few backend workflows are open to the internet, but nobody wants to be the one who looks. And the feature backlog gets longer, because building anything means first understanding everything.
I’ve taken on three of these apps this year, and the honest news is that the job has changed completely. Not because Bubble changed. Because the way I read a Bubble app changed.
The app can be read like a book now
Every Bubble app can be exported as a single file. Most people never touch it. But that file is a complete description of the app: every page, every element, every workflow, every data type and field, every privacy rule, every option set, every API connection, every plugin. It’s just laid out in a format no human would ever choose to read.
Using Claude Code, I built a set of tools that read it for me. Point them at an export and, in a few minutes, I have a census of the app. How many pages and elements. Every backend workflow and what it does. Which workflows create, update or delete each data type, and what triggers them. Which data types have no privacy rules at all. Which workflows are scheduled by nothing and are probably dead. Which fields get written but never read. Where the app calls out to a payment provider or an email service, and whether those calls are configured for test and live.
The last app I did this for had two dozen pages, close to five thousand elements, nearly two thousand workflows and sixty-odd data types. On paper, that’s weeks of clicking through an editor taking notes. The static read took an afternoon, and it turned up something nobody at intake had mentioned: the export had a whole mobile app inside it as well as the web app.
One warning before you try this at home. The export contains your live API keys. If it’s ever been emailed, dropped in a shared folder, or handed to a previous developer, treat those keys as disclosed and rotate them. That’s the first thing my tooling checks for, and it’s the first conversation I have with every new client.
The video is where the intent lives
The export tells you what the app does. It can’t tell you what it was for. Which screens are the golden path and which were an experiment nobody deleted. Which of the twelve roles on paper are actually meant to exist. Which “bug” is really a founder poking around at eight o’clock at night.
So before I read anything else, I ask the owner to record a walkthrough. An hour or two, narrated, in the test version of the app, working through five things: the path a real user takes, every other screen with a keep-improve-or-scrap verdict, roles and access as intended rather than as built, the admin and billing side, and the folklore — the quirks and workarounds everyone knows and nobody wrote down.
That recording gets transcribed locally on my machine, never uploaded anywhere. Frames get sampled every few seconds into a screen inventory. Then the transcript gets mined for every claim about intent that the other sources don’t state, each paired with the exact quote and timestamp. In my experience it is the single most valuable hour the owner will spend on the whole engagement, because it’s the only source that captures why.
It’s also where the tools will lie to you if you let them. On one project, two of four recordings turned out to be a single frozen frame for their whole length, with live audio over the top. On another, a quiet room made the transcriber loop for twenty minutes, producing a full-length, perfectly plausible document that was a third garbage. A transcriber has no error state for that. The only way to know is to read it. That’s worth remembering about AI generally: the failures that hurt are the ones that come back looking fine.
Then everything else, and every claim gets a source
After the export and the video, I pull in whatever else exists. Jira tickets and Confluence pages. The Figma files. Google Docs, spreadsheets, email threads with the previous developer, Slack exports, a folder of PDFs from a third party. My instruction to the owner is always the same: whatever exists, untidied. An owner who tidies first delays the job by a fortnight and hands over a summary where I wanted the primary source.
All of that gets triangulated. Every statement in the resulting documentation carries where it came from: a path in the export, a timestamp in the walkthrough, a ticket number. Where the sources disagree, and they always do, the disagreement is written down rather than resolved by guesswork. And every source I didn’t pull is logged too. A gap must never read as coverage.
What you get back
Not a hundred-page PDF. A tree of small, linked pages that reads like the app’s own wiki: the data model, roles and access as intended versus as actually implemented, the lifecycle of each important record, each significant workflow explained in English, the systems the app talks to, and a register of open issues. Every page links straight into the relevant spot in the Bubble editor. Every claim is marked as either confirmed from the file, inferred, or “the front end is obfuscated here and I’m reading the edges.”
Alongside that sits an audit. It works through the things that actually go wrong in Bubble apps: data types with no privacy rules, backend workflows that are public and skip authentication and ignore privacy rules, inputs that autobind straight to the database and silently skip every workflow that was supposed to fire, race conditions between “take payment” and “create the record,” and live configuration left blank so the app works in test and fails quietly in production.
The audit is a floor, not a verdict. A static read can’t see a guard that the front end implements at runtime, so every serious finding gets checked against the running app before I escalate it. I’ve retracted a priority-one finding for exactly that reason, and I’d rather do that than send a founder into a panic over something that was already handled.
And then, finally, features
This is the part that used to be the hard part. Once the app is mapped, adding to it becomes ordinary work again.
The recent example was adding an AI feature to a clinical-notes app: a design, a build plan, a click-by-click editor guide, and a validation pass. The validation is the bit I’m proudest of. After the build, a diff of the new export against the old one confirms the editor changed only what the plan said it would. A suite of assertions reads the new export and checks every field, workflow and setting. The last run passed two hundred and fifty-one checks and failed none.
The reason I bother is that every failure in an AI feature is silent by construction. On that same build, a name-stripping step had been miscompiled into a pattern that matched nothing. Because a later step also removed names, a dead filter and a working filter produced identical output. There was nothing a user would ever have seen. The audit was the only thing that could catch it, which is why the audit is the control rather than a nicety.
Where this is heading
I’ll say this carefully, because some of it is still in the lab. That export file turns out to be a two-way door. Bubble will take an edited one back. I’ve been proving, one construct at a time, that changes authored outside the editor land exactly as intended, checked four ways: in the file, in the editor, in the browser, and by a linter that runs before anything is uploaded. I can also render an export into a navigable local site, which makes reviewing an app a very different experience from clicking through it.
And for apps that have genuinely outgrown Bubble, I’ve done the measurement work on what a move to code actually involves, including a rather sobering finding about how much of a typical app lives in third-party plugins. If you’re at that point, ask me, and I’ll tell you straight what’s feasible.
If this is your app
If you’ve got a Bubble app that nobody fully understands any more, a builder who’s gone quiet, or a feature backlog that’s stalled because every change is a gamble, this is precisely the work I do now — I’ve written up how a takeover engagement runs if you want the shape of it. It’s faster than it used to be by a very large margin, and the output is something your next developer, or your own team, can actually read.
Send me the export, the last few Looms, and whatever documentation exists, in whatever state it’s in. Rotate the keys first. I’ll tell you honestly what shape the app is in and what it would take to get it moving again.