1

Hi Bubble community,

I’m building a logistics software company called Harlo, and I’m almost done with the Carrier TMS portion of the system. I plan to expand with additional systems like Broker TMS, Accounting, HR, etc., all under the Harlo umbrella.

I’m trying to figure out the best setup for my business. Should I:

  1. Build everything in one app?
  2. Split into multiple apps for each system?
  3. Use sub apps?

I want to ensure everything runs smoothly and can scale as the business grows. I’m also thinking about how this impacts things like database performance, security, and user management.

Any advice or experiences with similar setups would be appreciated!

Thanks,
Zakk

2

I’d do this, but it’s entirely determined by how competent you are and how scaleably you can build.

There’s much on this forum about performance scalability, but that’s the easy part. Product maintainability is the hard part - how do you effectively modularise and integrate various features of the app such that 1. new features are easy to develop and 2. modifying / revising existing features is easy and not fragile.

Reuseable elements are the answer to product maintainability, but it’s kind of hard to explain. As a rule of thumb, basically all of my apps now:

  • have all popups in reuseable elements

  • have all tables in reuseable elements with properties to show/hide columns depending on user type

  • have all group focus in reuseable element with conditions on each group focus items based on the current user’s permissions so they can/can’t take actions on a specific Thing

  • use option sets for screen / navigation

  • for thing ‘titles’, I call them tags. This is a tag for example:
    CleanShot 2024-09-17 at 15.59.45@2x

  • Have one reuseable tag for each data type. Then, inside the tag, you can configure actions like Go to page when the tag is clicked - e.g if a user tag is clicked, go to the user’s profile. That means that you can use the tag all over the app, and if you want to change it, it’ll be updated everywhere.

  • Other reuseable elements for things like empty states which are the same across app. Use properties for custom title/descriptions.

  • Same for action confirmations - those are the same across the app, so use a single popup for action confirmations with properties to modify the text/description inside the popup

Here’s my pages:

CleanShot 2024-09-17 at 16.01.31@2x
CleanShot 2024-09-17 at 16.01.31@2x1078×304 18.8 KB

Here’s my reuseable elements:
CleanShot 2024-09-17 at 16.01.53

Reuseable elements are king.

Not relevant

Debateable but would be more hassle than it’s worth

2 Likes
3

No Sub apps are for when you have a single app that you plan to white label for clients. So each sub app is the same as the main app with some differences for customizing to the client.

Not unless you expect to have the same user base for each and that each will be available for a single subscription fee.

That is what I would recommend for so many reasons.

  1. Easier to monetize the different systems as stand alone products, which sounds like what you want to do.
  2. Easier to scale one app while others are not, which is in the concept that maybe the HR really takes off, while the others are taking more time to gain traction.
  3. If you are going to continuously expand your product offerings, it is easier to have employees that are ‘product owners’ and teams of developers who focus on one product and you don’t have to deal with all the headaches of managing so many different people/teams accessing a single application, especially when somebody could goof up and throw everything out of whack.

There are more reasons, but the last one I’ll state is that for my own personal business, I take this approach. I have apps that are more customer oriented, while others are more service provider oriented, such as a e-commerce versus a POS. I could easily make one app have both capabilities, but I monetize them differently and ad spend on them differently and have different target markets…AND, I have the API setup in the E-commerce to pull from the POS, so that all retailers using the POS are automatically on the E-commerce platform, so it is super simple to share data between the different apps where appropriate and necessary.

1 Like
4

Thank you both for the incite, we are most likely going to build a hub based model, similar to Office 365. Our goal is to create interconnectivity, each app is complex in its own right, I am leaning towards creating multiple apps, connected via APIs. Either that or creating the TMS, which is essentially the same across both sides of logistics, as one app then adding other systems as additional apps connected via API.

If you have any other tips, I am more then happy to hear them!!

Thank you again
Zakk

1 Like
5

bf_bomb
bf_bomb2000×2000 181 KB

6 Likes
6

Don’t underestimate the increase in time that this would take compared to sharing one database with one set of users. Whatever option you choose, the decisions you make now are mission critical because if you get them wrong, you’ll be in big trouble down the road because of technical debt. Generally this is in terms of database structure.

If this is your first Bubble project, it’s a hell of a one to embark on an expect to start over a couple of times. So good luck!!

7

I am very much in support of the single app. You really need to build it correctly though from the start. Otherwise, this won’t scale and could impact performance, security and user management.

I have helped create VERY large apps on the Bubble ecosystem. So I know that Bubble can handle it if you build it correctly.

Also, I have specifically built out a huge TMS that had it all in one and it worked fine, as long as you are ok with most likely switching over to an Enterprise Plan, once you need to, as it scales.

It was a very large project that took over two years or so to finish. The client did most of the work themselves but we were heavily involved in the process as well.

Hope that helps. :blush:

1 Like
8

Yeah, I have built a lot of test projects in the past but this is my first full build out. I feel that it is coming along good, major work in workflow efficiency and complex workflows in general. In the next few weeks I am going fully focus on API integrations with systems like Motive or Omnitracks, these are major systems used in my industry. I really appreciate the help and words of wisdom.

9

Yes, it really does help to know that large apps can be built on bubble. I like the idea of using multiple apps for the modularity, but I can also see the potential weaknesses. I have one question: in its current state, my app has most pages laid out. For example, I have one ‘View’ page that changes its layout depending on the data being displayed. I also have other pages like Loads, Drivers, Equipment, etc., which provide overviews and search options. Is it okay to keep these pages separate, or should I consolidate them into one page that dynamically changes based on what the user wants to view?

I am just concerned that this could take an impact on performance if there is too much on the page, even if it is hidden. I could be totally wrong in assuming this but please let me know your opinion.

10

Make it so they can change dynamically…you don’t want the page load time when a user switches between them

You can make it so each one is it’s own group hidden based on conditions, and ensure you do the correct search constraints to show only those that match whether it is for Loads, Drivers etc.

11

There is definitely a balance between pages and reusable elements. If I were you, I would have one ‘dashboard’ page and multiple reusable elements on the single page. There are some good reasons to have other pages as well. For example, I would have one admin dashboard and most elements on that page would be reusable elements. I would also use page parameters to more easily communicate between the elements.

There might be a separate dashboard for drivers/owner operators, especially if their view is going to be completely different than the others. Or there might be a separate one specific to drivers/owner operators that will be using their phones and you want to build it out mobile-first. Maybe a different page for clients too.

So there is just a balance that you have to find. I don’t think there is just one perfect solution but there are multiple ways to make sure it scales. These are just my suggestions from my experience. Others might feel differently too. :blush:

12

100%, I have a couple of pretty complex search workflows that I use URL Params to hold data and whenever I change a page in my “view”: for example driver “view” switching from General to Profile. but most of the other pages are dynamically changed. I reason I use the URL Params is because I want the user to be able to copy their URL and send to a coworker if needed.

13

Yes, I am trying to for sure find that balance. I am pushing really hard to make sure it is scalable, our first beta tester has about 1000 loads a month so I want to make sure no issues will arise, I am sure they will but I am doing everything I can mitigate that.

It seems like most things I will find my own way along the process of doing things but I am doing everything I can to keep workflow units down and the balance of simplicity and complexity up. :blush:

Thank you both again for all the help!!

1 Like
14

Glad to be of assistance. If you need anything in the future, don’t hesitate to reach out directly and I will see what I can do to assist. :blush:

1 Like