Principles

Here are some general principles that we use when thinking about Bubble development.

Measure twice, cut once

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. However, over time, due to all of the quickly delivered features, the Bubble logic gets very convoluted, poorly structured, and layered on top of each other, which means eventually it actually becomes more difficult to maintain and build on than code.

Bottom line is that you shouldn't let Bubble lull you into a false sense of "this is easy" and stay very disciplined, carefully planning every feature and making sure that you're building for maintainability and scalability.

Find the simplest way

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 be as clean & 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.

Think in modules

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 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, and more. We'll talk more about these later.