Our company has now successfully made the shift from starting in Bubble 3.5 years ago all the way into full conventional web stacks. Bubble gave us our big break those years ago and the ability to validate and quickly iterate, and for that we are very grateful. We were blessed to have a successful idea that spawned into multiple products and continued to scale and grow into something truly life-changing. As with all things that scale, the time eventually came for us to make the transition into conventional code stacks for in-house enterprise control and rigor, but I wanted to leave some breadcrumbs for others whom want the assurance that, if they start on Bubble and hit gold, there is indeed a way forward should conventional code be their ultimate destination (Bubble has grown significantly over the years in productionionalized disciplines and some members may be fine staying with them indefinitely, but our scenario ultimately required conventional). The below was just our roadmap, there’s many ways to scale and there are other well-versed members lurking here that have alternate valid paths. Every step comes with new levels of learning required and the full roadmap would take typically years.
-
Learn to build an app fully using in-house Bubble tech. The level of conventional code knowledge you need here is minimal, and you can cut your teeth on learning site navigation and DB modelling, API’s, and Stripe.
-
Dev in Bubble with more “conventional” thinking. To be pointed for conventional, learn to avoid using “Lists of things” in your DB, as they are non-enterprise standard. Instead, stand up a separate table with such “things” with their own Bubble-generated unique_id’s and then add separate “crossref” tables of whatever you need between the driving table and the reference “thing” table (which will turn into much more tables but that’s ok) (these are also called many-to-many tables). Also, on the front-end, code exclusively using custom states to get you used to how a majority of conventional front-ends work. (Custom states can just get piled up at the top page level). Every data element on-page ties to a custom state and CRUD actions engage the custom states only. For front-end design, use “Styles” as much as possible in your elements (which are essentially CSS classes)
-
Bubble’s internal DB is very fast and decently auto-indexed for non-relational queries (such as fetch a User form the User table, even if users are in the millions). But it will hit a wall fast when you start needing highly-complex joins and your features list grows in a complex app. Learn SQL. DDL to create tables and DML to perform your CRUD actions. Learn how to code in an enterprise grade DB of your choice. Bubble itself is built on Postgres, which I personally like as well, but there’s a plethora of other options. Most apps require just a standard relational DBMS, with a few exceptions. Once you’re ready, start using Bubble’s SQL API plugin to develop entire apps using a conventional DB stood up on some external provider (DigitalOcean, Aiven, etc). Proceed to unlock the power of stored procedures/functions in your DBMS to handle triggered actions or huge bulk data actions on events. Note, Bubble doesn’t pool/cache external DB connections, so they’ll automatically be a bit slower for those simple queries throughout your app, but the savings you see on complex queries exponentially outweighs it.
Note, if you have a lot of active userdata on Bubble and need to port it out, it’s at this point you’d need a dedicated cluster and request a read-only DB connection to your internal DB. You can then port it out via your DBMS editor or a more powerful tool such as Talend Stitch. Bubble typically requires IP whitelists for this, so you may need to grab a dedicated VPN to accomplish.
- Utilize your own S3 storage. Pick a provider and start using the necessary API’s to push/pull files, such as for user photos, uploads, etc. Learn how to store and retrieve S3 ID’s in your DB to keep you S3 storage clean when artifacts are signaled to be replaced/deleted by members. If you have files already on Bubble’s S3 (AWS), you’ll eventually need migrator processes to copy and move them into your own S3.
Following the above, you’ll be best positioned to tackle relearning front-end. Start learning HTML+CSS. There is unfortunately no simple way to convert Bubble front-end pages into conventional, you will need to recreate them from scratch in your future conventional framework (which for us, was Wappler as the next step), but all of them will require HTML, CSS, and knowledge of breakpoints (which are the “responsive” device sizes you can choose in Bubble).
Additional hard points of what Bubble handles for you, and that you’ll have to tackle going into conventional: security provision (user logins and such, luckily some frameworks out there give you a good leg-up on this aspect), timezones, and building the backend scheduling engine (whether done in your conventional framework or via cron inside your DB)
We had a successful app out of the box in Bubble, so we had to ascend this list incrementally and it took years to do it without disturbing the userbase. I guarantee you others have different ideas and those are welcomed, but we wanted to share the rough roadmap we took to encourage others that, yes, if you start on Bubble and get successful, there DOES exist a roadmap to conventional should you desire it and are willing to put in the serious time to learn. I simply wanted to share this as a give-back to the community I’ve been with for many years. Happy trails and happy Bubbling!