Principles
Here are some general principles that we use when thinking about Bubble development.
It's much easier to use Bubble than it is to code, which makes it tempting to jump right in when trying to build something or change something that you've already built. That's usually a bad idea because you're much more likely to end up with a "Spaghetti Bubble App" (see Spaghetti Code), which is difficult or impossible to maintain and iterate on. What you should do instead is carefully plan and structure both your initial functionality and ongoing improvements.
Imagine this scenario (which we've seen multiple times): A startup is using Bubble for their SaaS product. The Bubble development team builds an initial version in a few weeks, which makes the sales team very happy. They go out to try to sell the product and start receiving feedback right away. Their first potential customer says, "If only your product had X feature, we would buy." "No problem," replies sales. They go to the development team and in just a few days, feature X is live. The potential customer is amazed and the first sale is made. This continues over and over again until sales gets used to the gratification of being able to quickly deliver any feature that customers ask for.
This model of development is not sustainable without factoring in the costs of maintenance that come with ever-increasing app complexity. Creating an app with all of those requested features would require substantial revision after every couple deliveries, or a smaller amount of up-front planning if the client knows which features they want to include in the application.
Over time, when an app is built by adding on many quickly delivered features, the Bubble logic gets very convoluted, poorly structured, and layered on top of each other. Eventually it becomes very difficult to maintain and build these applications which are filled with band-aids instead of thoughtful planning, which undermines one of the main advantages of using a no-code platform in the first place.
The bottom line is that you should stay very disciplined and not let Bubble lull you into a false sense of "this is easy." A well-built development process includes carefully planning every feature and making sure that you're building for maintainability and scalability.
Blaise Pascal famously said, "I would have written a shorter letter, but I did not have the time." The same can be applied to software generally and Bubble applications specifically. It often takes much more effort and mental energy to come up with a simple way to do something than it takes to come up with a hard way to do it.
If you think about some of the most successful tech products as of late, these principles hold true. Uber, Slack, Stripe, and more all launched with a minimal set of critical functionality. All were easy to use and not bloated with unnecessary bells and whistles.
You may not be looking to build the next unicorn but the the lessons are universal:
- Eliminate any functionality that's not absolutely needed right away
- Make the UI as clean and simple as possible
- Decrease redundancy in your pages, workflows, and database structure
Making things simple may indeed end up taking more time than making them more complex. But the result will be a product that's easier to both use and maintain.
Modular structures are everywhere. Buildings are modular from the elevator (big module) to the brick (small module). Legos are very obviously modular. And our Bubble apps should be modular. Why? A few reasons:
- Modules have clearly defined inputs and outputs and can be plugged in anywhere without requiring duplicate work
- Modules are self-contained/independent and can thus be safely updated without affecting the rest of the application
- Modules allow multiple people to work together on a single project and then combine their efforts
- Modules structures are easier to understand
There are many ways to create modules in Bubble - through reuseables, custom workflows, API workflows, data triggers, and more. We'll talk more about these later.