The first Bubble app I managed end to end looked like a success. We shipped in about nine weeks. The client was happy. On the demo call the screens loaded, the workflows ran, and someone on their side said it looked better than what their last agency had built in four months.
Nothing crashed. No missed deadline, no angry email. Just a working app.
About five months later they called about their Bubble bill. Their workload units had gone well past what they had planned for. I went back into the editor to find out why, and found the data model I had designed in week two — before I understood how they would actually use the app. Every search was scanning more data than it needed to. Every page load was paying for a decision I made in one afternoon.
Fixing it was not a fix. It was rebuilding the foundation with the house already on it. Forty thousand records and around two hundred workflows all assumed the old structure. We did it. It cost more than the original build.
What I did not know then
Barry Boehm published data in 1981 showing that a defect caught during requirements costs about a dollar, and the same defect caught in live operations costs two hundred to a thousand.
You have probably seen a louder version of this — "bugs cost 100x more in production." That number is weak. It comes from internal IBM training material, not a study, and researchers like Bossavit and Wayne have taken it apart. The exact multiplier is not reliable. The direction is. NIST confirmed it in 2002, and Capers Jones found the same pattern across twelve thousand projects.
In Bubble, this means a wrong data model on day three is a conversation. The same wrong data model in month nine is what happened to me.
Bubble also prices this in a way that is easy to miss. Every search, workflow and API call uses workload units. Overage is around thirty cents per thousand, with no cap. A badly structured database is not a one-time cost. It is a monthly cost that repeats for as long as the app runs.
The other thing I found was security nobody had checked. In Bubble, permissions live in Privacy Rules, and they sit in a different part of the editor from the UI that appears to hide the data. Auditors report that most Bubble apps they inspect have at least one data type with no Privacy Rules at all, which means that tables can be read through the Data API. The screen looks locked. The network response is not. I had never opened that panel.
Why I did not stop sooner
I had a feeling in month three that the data model was wrong. I talked myself out of it. We were moving fast, the client was pleased, and reopening that decision meant telling them the last six weeks needed revisiting.
There is research on this. Barry Staw's 1976 paper Knee Deep in the Big Muddy found that people commit hardest to failing projects when they chose the project themselves. Admitting the build is wrong feels like admitting you are wrong. Researchers at IESE found that people with strong track records are the worst at stopping projects, because they expect to be able to fix them.
I was not ignoring the problem. I thought I could out-work it.
Six questions to ask before you sign
Show me the data model, not the demo. Screens take a day. The schema is what you are actually buying.
Forecast my workload units at 100, 1,000 and 10,000 users. A team that cannot do this has not run an app at scale.
Give me a Privacy Rule for every data type, in writing. Not "we handle security." A document.
Make it smaller. Standish data across decades shows small projects succeed around 90% of the time and large ones under 10%. Every instinct pushes toward more scope. Push back.
What is the exit plan? Bubble does not export source code. Where does the data live, and who can pull it out?
Who stops this if it goes badly? Name someone who was not in the room when it was approved. The person who started a project is usually the last one able to stop it.
None of this failed loudly. It was a series of reasonable decisions, made in the wrong order.
If you are mid-build and something feels off, it is usually the data model. Get someone else to look at it before you spend another month.
We run GoldenAxe Technology Solutions, a Bubble development team. If you want a second opinion on your data model, workload units or privacy rules, send me a message. You will get a straight answer either way.
