At what point did your Bubble app become difficult to maintain?

Need help
1

I’ve been thinking about this while working on a team project ( at Girmairi).

When an app is still small, everything can feel pretty manageable. You know where the workflows are, the database structure still makes sense, and changing one feature doesn’t usually affect five other things.

But I’m curious about what happens later.

For those of you who have worked on Bubble apps for a longer time, was there a point where you realized:

“Okay, this is starting to become difficult to maintain.”

Was it because of:

  • too many workflows depending on each other?
  • the database structure becoming harder to change?
  • repeating the same logic across different pages?
  • too many plugins?
  • several developers working on the same app?
  • performance getting worse as more users or data came in?
  • simply not documenting enough decisions early on?

I’m especially interested in mistakes that didn’t look like mistakes at the time but became painful months later.

For example, maybe something felt like the quickest way to build a feature at the time, but later made every new change harder. Would really like to hear from people who have taken a Bubble project from a relatively simple build into something much larger.

2

The worst issues I have seen are apps built by very bad or new developers causing a lot of technical debt that make it very time consuming and expensive to fix.

Privacy rules not being done properly or sometimes at all.

Bad database structure.

Sometimes just bad naming conventions can be horrible to sift through.

3

:white_check_mark: Especially with bad naming conventions and a bad database structure.

4

I would say you start noticing maintenance difficulties when you haven’t taken the time to plan your product on paper before moving to Bubble or code. I mean, you start in the editor with an idea but no plan, so you end up implementing the same elements on different pages rather than using reusable elements, and creating or deleting fields and databases to cover cases you hadn’t thought about before. In a few words, you end up with bad naming, poorly structured database relationships and workflows, duplicate or triplicate elements, and patches everywhere.

Today, if I had to start a new project, I would first think about the structure, relationships, database and option set structure, naming, etc. Try to think through all the parts of the project before starting to build it. And once you’ve built it, create documentation. This will be useful when you come back to certain parts a few weeks later, or if you want to hand the project over to someone on your team.

And finally, you can use Buildprint. Honestly, with Opus 5.5, things move so quickly. But of course, you also have to stay organized here, otherwise you’ll get lost in the discussion…

5

In addition to everything that has already been said—and what will likely be said—I would add that…

Well, there are some projects that are gradually changing here and there. For example, if you are working on a growing app that constantly requires new features and implementations, one thing is almost certain: you will need to tweak the database here and there, adding new data types, fields, option sets, and so on.

This is common for apps like these and then you will need to plan the data migrations to populate new fields/datatypes (where applicable) and remove old ones (in the past I used to put a prefix on these old things to remove them after everything was done, something like “DEL_”, but now Bubble implemented one way to flag these fields.

And, you know… not everything needs to be created as reusable from the start like reusable element, reusable event, backend workflow, or even a global variable (a feature recently implemented by Bubble). However, you will start to recognize the need for these as you start to see repetitive patterns emerge. This is also normal, some developers anticipate future repetition and build with a reusable architecture from the start, though this isn’t necessary in every case.

In other cases, you might find yourself using these reusable artifacts not because they appear in multiple places across the app, but simply to consolidate logic, a screen, or a workflow into a single, centralized location.

You should also use colors in your workflows, give them descriptive names, use folders to separate logic and flows, and adopt a naming convention that makes sense to you but without making a mess.

There was a time when the element tree didn’t use icons to distinguish between elements, so some people used emojis to identify them, and I believe, some still do.

I picked up some habits from that era, so even today I still use “:recycling_symbol:” for reusable elements . You know, some people are more visual than others :sweat_smile:. However, while some people use emojis in the names of option sets and elements, you should avoid using them in the names of data types, fields, options within option sets, and so on, they can cause problems over time and end up creating a mess rather than helping.

And yeah, documenting everything you can is incredibly helpful, while documentation should be an essential part of the process, I understand that it isn’t always easy to document things when the speed of creation and constant changes leave you with no spare time.

So, at least, you should focus your attention primarily on the most complex parts. If you can’t produce written documentation, try making videos. I personally like making videos for myself to explain complex workflows, in addition of written documentation.

This is different from the well-organized written documentation a project ideally requires. Fortunately, there are tools available today that can assist you, such as Buildprint.

6

image
image620×404 56.7 KB

7

I have few apps in development and maintenance for years.

  1. Proper conventions for naming data types/fields, elements, workflows, and other. Colors and folders.
  2. Extensive use of reusables
  3. Screen recording of delivered feature including front-end walkthrough and bubble setup (workflows + serverside)
  4. Trained Claude Code skill that answers any question related your app (runs locally on your machine, fed with the app’s export JSON).
8

wait why not just use buildprint, it’s like 10x better and it’ll build your app for you….

9

actually maybe I’ll make a local Buildprint mode so you can point it to an export and don’t even need a Buildprint account to read it