New here. Bubble looks great, what's the general workflow?

Hi all,

Thought I would say hi and introduce myself (Dan :wave:). I usually jump to Wordpress + CPT (Pods) to build out my MVPs. Today I hit a massive roadblock and asked myself the XY question. (For those that don’t know,XY problem).

I was searching Google and stumbled on Bubble for the second time. I must admit, I was a little dismissive at first but now I have dug a little deeper, I think its mind blowing what is being made here and what also is facilitating others to do.

Point of this post. What are peoples general workflow when approaching a new project? Do you start from a complete blank canvas, start with templates, are there quick hacks to get certain structures together?

For example, I wish to build something similar to Task Rabbit but not as complex, focused in one industry and more catered. For this I would need user accounts, 3 roles (Admin, Customer, Provider), a messaging system and form submission. Its also location based so will need use of the Google API Gecode facility and that will tie in with whether the provider is close enough to the customer or not. I will also need triggered emails.

Knowing the above, how would you approach such a project? Instead of me reinventing the wheel, you can just do this, this and that for example.

Any help is much appreciated and I look forward to hearing how people approach their projects!



Welcome Dan.

If you’re looking to build an MVP, then I’d recommend looking at templates from zeroqode first. I believe they have a template that’s similar to Task Rabbit.

I suspect this gets you a good design, general page layouts, all of the basic logic and workflows to navigate through things. You’ll probably want to then adapt some of the features, add others that may be necessary, customize all of the language and generally make it yours.

You may want to test the template to ensure it handles enough of the edge cases you want to support out of the gate. It surely won’t be production grade ready, but that’s probably better because it makes it easier for you to change and adapt to suit your goals and feedback/insights from the market.

I’m sure others will chime in with additional ideas. Best of luck!

Welcome to Bubble, good to see that we’re now up to @dan8. Perhaps I should change my username from @dan1 :stuck_out_tongue:

From my (slightly opinionated) process standpoint, I try to do a lot of work (planning) outside of Bubble at the outset of any project. (It’s good to remember that Bubble is one of the many tools in your arsenal of building a startup…not the only tool.

Bubble makes it too easy to build. So, for many, it’s tempting to start building right away and throwing more things at the canvas as you go.

So, step one is to validate that you have an idea worth tackling. Do not build your sketches in Bubble - otherwise you’ll be tempted to turn those “sketches” into the actual application.

Then, figure out what the baseline of your application is. I do this using my basic app skeleton document ( (Note: it’s not entirely intuitive for community use, the purpose is to determine: who are you building the app for, what it should accomplish, what data you need to capture to accomplish this and what the basic form should be.

My belief is that it is vitally important to get the right problem first, then define a reasonably good database structure to tackle that problem, then to figure out the general interface for how you will enable users to interact with your system.

Above all else, it’s good to have a fundamental understanding of how Bubble works and what it means to be a programmer (that just happens to be using Bubble). I think @keith’s comments here capture it quite well: More Bubble tutorials

Dan (creator of LearnTo - 15+ hours of Bubble tutorials and live coaching)


Thanks @sridharan.s, I will take a look. Regarding workflows, is it counter productive to start with something like that and start stripping out what you don’t need (does it affect the functionality to a point that makes it more time consuming?) or is it still a massive gain vs starting from scratch?

@dan1 I have only just noticed! I feel committed to it now so shall retain it. I feel I should absolutely be consuming a much resource as possible on learning the in’s and out’s of the bubble platform. Most would see it and want to jump in straight away but I would almost feel a guilt to myself by doing that.

Regarding the viability, I have fortunately completed this stage already. I was building out a working demo in Wordpress using custom post types and PHP snippets. I created a function to pull in Long Lat from geocode API but then I hit a brick wall and it was this wall that lead me here! The flexibility that Bubble offers along with a visual UI just seems to me the better way.

1 Like

Good question. “Coding” with Bubble allows for a different process flow than traditional coding, to a large extent. Additionally, it’s hard to architect a good solution in Bubble before you’ve used Bubble considerably because Bubble works a bit differently than custom code.

Unlike traditional coding where you might want to start with, say, Twitter Bootstrap and then design your pages to fit into its’ 8 column structure, Bubble enables you to change anything on the UI at any time without near as much trouble. So, the need to over-plan for the UI is removed. Of course, you still want to think through the UI so you can design something that’s useful and intuitive for users, but you no longer need to do much planning for the coding/implementation process itself.

I’d say it’s similar with Bubble’s workflows as well. Most of the time, you can simply update workflows and refactor as you go. Bubble abstracts much of the complexity so it becomes relatively quick/easy to manage all of this.

So, most of Bubble apps seem to be something that you can update on-the-fly. Of course, there are still components that require architectural thought such as the database schema, where/how you interact with 3rd party tools, etc. That said, the way to do these in Bubble may vary a bit from how you’d implement them in custom code so planning too much can be counter-productive.

In fact, the right architectural solution in Bubble often differs from the right solution with traditional custom code because Bubble’s functionality differs from custom code and has a different set of trade-offs. For example, while with custom code it’s best to write DRY code and not replicate your data in the database, with Bubble you’re more likely to want to break these rules. It’s still not ideal to break them, for sure, but breaking them a bit sure does make it a lot easier to create a performant app in Bubble so people do break them more. So, I’d be careful spending too much time architecting how you’re going to code your app before you really understand Bubble and have dug in.

The traditional theory on how to code an application is only 80-90% right with Bubble and that 10-20% difference can really bite you in the butt. After you’ve learned the basics of Bubble (e.g., by taking a 30 hour video course or something like that), I’ve found it’s easier to implement Bubble by digging right in. Sure, you’ll need to change course and refactor your approach at times, but this is usually quite straightforward in Bubble.


BLUF: if you want to learn Bubble you have to build things in Bubble. It is worth learning Bubble so you can build rapidly.

My favorite thing about Bubble is that everything is integrated together. The database, permission logic, workflows, UI, etc all know about each other automatically. So if you add a field to the database and give it a type (ex. number) the UI elements that interact with the field instantly know it’s a number and only show you appropriate options.

Of course, this means Bubble has strong opinions about how you’re going to build your app.

My least favorite thing about Bubble is that you don’t have all options available at all times. Most of the options are buried several levels into the stack where they actually get used. They are only discoverable by actually building the entire stack to the point where that option is useful and then using that option.

So I suggest the best way to learn Bubble is to build several apps. You can’t learn Bubble by reading the documentation or bringing in your intuition from other tools. The only way to work with Bubble is to build a mental model of Bubble’s structure, where certain options appear, and how to get to them.

As for what you can do in Bubble, it’s awesome for CRUD apps and terrible for manipulating data.

if you can get by just storing and retrieving facts you can get up and running in Bubble in a day (with experience) and probably scale big. If you need to do math, or complex queries, or analysis, you aren’t going to be able to do that in Bubble itself. There are a couple little things you can do, and the team is adding one or two more things every now and then, but you shouldn’t rely on it.

Bubble has a “no code” metaphor that breaks down pretty quickly when you actually need to do work. What Bubble offers instead is basically code that you build using pulldown menus. There are also an increasing number of ways to use actual code. The workflow system is the weakest part. It’s very linear and hard to organize. For example, if you need a branching path, you can’t use one logic operator (like an if-then or switch). You have to put redundant logic into each branch of the path. There also isn’t a built in way to comment-out a part (you have to hack it by creating an if that will never happen). There is a similar linearity problem in the conditions on UI elements where you have to reproduce the same logic across all the condition statements.

An annoying problem in some circumstances is that the client side downloads the entire record (all fields) that are allowed by permissions. So if you know optimization is important it can be worth splitting data across tables from the beginning. Like if you know you’ll have a lot of different information for a user, but it’s all relevant in different situations, you might put it in different tables so you don’t have to download all of it when you access the user.

A trick that will help save you some headaches is that Bubble’s stack does know about elements and their changes, but you can’t hot-swap elements. For example, if you have element A and elements B, C, D, E, F, G, H, etc all depend on A, and you want to replace A, you’re going to have to go fix the link in elements B-n. But if you make an element just to be the nexus of all those links, then you can swap out element A and only fix one link.

If you know your interface needs to work well on mobile (small screens) you should build the UI in the smallest width you support and have the responsive logic pull things up onto the same line, rather than the other way around. The way the UI is built and the way it displays is tightly coupled. For example, the actual number of pixels between elements in the editor is an important part of the responsive logic. I’ve had bugs where responsiveness got all screwed up and eventually found it was because a group that was 320px wide changed itself to 322px wide, which made it wider than the screen group it was inside of, which totally changed the responsive logic. Along the same lines, the relative y position of the elements is extremely important and there’s no insert or wrapping like in a text editor. It’s good to get in the habit of designing your pages in the editor with empty vertical spaces between them, putting an invisible group in that space, and setting the group to collapse when invisible. That way the displayed page looks right, but the editor page has room for you to insert new elements without having to manually reposition all of the lower elements.


Thanks @blueback09 some great insight there.

I like the approach to being mobile centric first and then expanding for larger screen size.

The hindsight for branching out data for records that will be hit a lot is nice as well.

I totally agree with using it to learn it. Im going to complete the intro’s, will take a look at some other bits so I have familiarity with the workflow and then will just build out some stuff and see what happens.

The application I will be building out is 90% CRUD, it needs some calculations using geocode to work out a proximity to records and then notify based on rules. From what I have seen , I believe this will be totally achievable within Bubble.