Its Easy to Scale Users, but Its Very Hard to Scale Features

Tips
1

In the next 2 or so minutes, I am going to save you a lot of money if you want to get your app built, save you a lot of time if you are building your own app and how to scale features if you have an existing app

Just as some background, I have been a full time bubble developer for over a year, and my agency has helped over nine companies build amazing softwares

The Problem

I was speaking with a traditional developer last Friday, and he told me that it’s easy to build an app that can scale in terms of users, but it’s very hard to build an app that can scale in terms of features

In my experience, I can attest that this is very true and I think it is one of the major differences between good developers and great developers

Speed is a problem (sorta)

A lot of apps are primarily focused on the speed of development. While this is great, most developers take it too far, they compromise on quality and a proper scoping phase to understand what the client wants now, and what features will come in the next 3-36 months.

When proper scoping and speed is prioritized, it means the developer hasn’t thought about

  • How structure the database to accommodate new features the client has talked about wanting in the future
  • Or how to create a design system that allows you to build new pages on an app without having to reinvent the wheel
  • Or they don’t use proper naming conventions on elements and workflows, meaning when you have to edit the app in the future, it will be a mess and will take far longer than it should. (meaning more cost for the client)
  • Or workflows are not sorted in folders and colors, and no notes have been made on the app

The Result

In the short term, you have software that works, but in 1-3 years, you will reach a breaking point.

This is when companies say that bubble sucks and they have to spend hundreds of thousands of dollars to swap to traditional coding to scale their app further

But if the app was built with a solid base and consideration for the potential features that will be added in the next 3–36 months and with proper build practices

It can allow a company to scale features faster, cheaper and in a manner that follows good development practices instead of just duct taping new features on every update

Conclusion

If you like to save time and money, getting your app built, I would do the following

  • Never go with cheap developers, this almost always ends up in a low quality application that will need to be rebuilt in the future (Costing you more money!)
  • Have a roadmap of all the features you want in the future (this can change, but its good to think about), and when you are interviewing developers, ask them how they will build the app to accommodate these features
  • Find a developer who has experience building and maintaining large databases, I have worked in apps with 100+ data types (with 1,000,000+ records) and I can say that the experience has made a far better developer

If you are building your own app

  • I would recommend reading Peter Amilies books if you haven’t already
  • Spend a day building a database scheme before you build your app
  • Map out what features you want in the future, and your plan for building those features

This will allow you to find any features that will not work with your current database structure, and how you can change your app now to facilitate these features

  • Get some coaching if you have the budget, you can spend a couple hundred dollars for some coaching and I can guarantee it is worth the investment

If you have an existing app

  • Speak with your developer about the features you want to build in the future and get them to see if the features are possible with the current structure of the app
  • If your app does not have proper documentation and organization, I would highly recommend investing the time or money into this, it makes building and maintaining the app far easier
  • If you got your app built by someone else, I would recommend getting an App Audit, My agency offers this service for free, and there are paid audits offered agencies like notquiteunicorns, founded by @georgecollier

So how can you make your apps more scalable?

2

Probably the best suggestion…also, don’t forget naming convention on Data types, option sets, styles etc.

I always use only folders, no colors as when you do, the more workflows you add, the more the workflows section just looks like a mess of color causing it too be even more difficult to navigate.

One of the best features Bubble has added to the editor that most likely is very under used. Best to have notes on data types, data fields and option sets to describe how they are used, ESPECIALLY how they will be used in the future for the purposes of remaining on topic of the threads title, plus on elements that are not always visible to describe what the conditionals used would actually mean in simply language.

I think one thing that is overlooked here as a tip to remember on how to be able to easily manage the app, is to become very very familiar with the App Search Tool and all the different things that you can use it to help with.

Yes, the Styles section is a must to be familiar with

Good advice even if the client doesn’t expect to add new features in the future

What kind of app required that many data types?

3

+1 to @boston85719 on not using colours. Without a legend, it just looks like soup. What’s pink to one developer is meaningless and distracting to others.

+1 on @petter 's book reccommendations.

Great post, however I disagree with this:

“Map out what features you want in the future, and your plan for building those features”

If you spend too much time thinking about future features you may never build, then you never finish the features your customers and market want today.

One of Bubble’s strengths is how fast and easy it is to refactor apps. Follow basic principles and you can leverage this great strength unique to Bubble.

I think getting your first paying customers is better than never shipping a product that could have scaled to a million customers. I don’t think many companies stick to three year roadmaps.

+3 on naming conventions. I’m personally baffled why people use snake_case or camelCase for database field names when you can use Normal Terms and match Bubble’s default naming format (Created By).

Question: What naming conventions have you come up with for groups? At some point you get nested groups and it becomes difficult to think of meaningful names.

4

With all elements, whether they are groups or not, I always keep the element name, so Group A, I will change to Group Product, or Input A I will change to Input Product Name, this way I always know what type of element it is, and so would any other developer that comes into the app editor. I hate seeing other developers using names like grp_ as 1. there is extra work involved in highlighting the word Group and changing it to grp and 2. Not every developer will know what all of the acronyms somebody else came up with would represent.

In terms of nested groups, it depends on the situation and layout. Sometimes, row layouts, I might have a nested group as group left and another group right, but other times it might be group name/age to indicate what type of values are displayed or captured by elements within the group.

I use the name of Group Container a lot when I know I will be nesting other groups (this is used for the main parent group). It can be a challenge when it comes to nested groups, but ultimately I just try to stick with giving them a name that is representative of the data displayed or captured within the group. And I NEVER leave them as the default that Bubble would come up with since they always just take the content type, so you’d end up with Group User, Group User, Group User all over the page if the content type of the group is User.

5

Always stick to 1 naming convention for each element type as well

I have an app I am working on that has some popups named as “POP UP_“Name””, some as “POPUP “NAME”” and some as “POP_UP “NAME””

So every time I want to show a popup its a total headache

Yeah fair enough, I find it good for sub-categories, inside of a folder, also when a workflow is not functional or disabled, I always make it Red

100%, it makes an app so much easier to build!

Its a project management, a CRM, an issue tracker, a form response tool and some high level automation

So its kind of a meld between a lot of apps, hence the 100+ datatypes

6

I think its important to do, but you shouldn’t over do it

I am not saying you should spend 2 weeks working out a 5 year roadmap for the software, but have an hour call with the client (or an hour by yourself if its your app) and figure out the high level plan of the app

For example, if you are building a Job Board for housecleaning in a niched down area (like 1 city or 1 state), have a call with the client and ask if they want to expand into different areas, different services, what kind of search parameters they would want on the job board (this is super important, especially for complex apps)

It will just give you more information for when you map out the database and starting actually building the app

I would say simplicity and consistency are the most important things, stick to 1 naming convention, you can have it complex, but I just do plain English so I can understand it. If you start having more then 1 naming convention it makes the app a lot harder to maintain

7

Can you give some examples of how you name nested groups?

8

Can you give an example and I will give my naming conventions for it