21

No need to apologise because maybe you can educate me on something I am missing. Let me paint the scenario if I may:

Say I am creating an app for a crowdfunding service. Such an app’s design would have a main user, his project manager, and thousands of users in his app “the crowd”. If I did this Saas style it would mean this that I just mentioned x the number of successful users I get to use my app. So its thousands x thousands.

And each app would need to be under its own subdomain. Are you saying this is feasible on Bubble?

22

If you or anyone else can convince me that the Saas model can work with no major issues I will seriously reconsider my business strategy and I am not being facetious.

23

Okay, let’s use your crowdfunding service example, and let’s call your service Kickstopper. Who are you trying to sell a copy of the Kickstopper Bubble app to? To every person who wants to start a Kickstopper project in order to try to get it crowdfunded? In your example, who is the main user, and why does he personally have his own crowd? Is that crowd supposed to be stored in its own database that’s not accessible to some other “main user” who has their own version of Kickstopper?

At this point, I’m not sure the question is about what is or is not feasible on Bubble… it’s what are you trying to accomplish… and again, my apologies, but I’m just not getting it.

1 Like
24

I prefer not to write about my specific use case on the forum at this stage so i will Dm you if you dont’ mind

1 Like
25

I have created (for myself and clients) many SaaS apps and they all work no issues in Bubble (yes even larger scale).

I will caveat that by saying you need to build the database and UI in a performance optimised way as well as be on the appropriate capacity plan for your use case.

You can of course build really badly on Bubble and have really badly performed apps prone to bugs…but that is the builder not the tool :slight_smile:

3 Likes
26

Thanks for sharing. I am seriously considering changing my idea to an Saas model now. But just to make sure we are using the same definition of Software as a Service, in my case each single user who signs up would be a company owner and would have hundreds of employees and clients who all would have accounts on his app, with documents being uploaded and things being created each day. Is this the type of Saas you say can work if designed properly?

Also, have you been able to make it that each user can link their iteration to their own domain name?

Finally, if you have any resources such as videos or even paid courses that deal specifically with building databases for Saas model apps on Bubble I would much appreciate it.

27

Yes that is certainly one example of SaaS and similar in structure to some I have built.

I haven’t linked to individual domains/subdomains but I have created personalised URL’s for example www.yourappname.com/account/customer-name. I believe you can have subdomains/domains…just search the forum. You can even white label the app so that each customer’s branding is what their own customers/users see.

There’s really not much you can’t do with Bubble if you are creative, curious and good at solving problems.

28

Ok back to the drawing board it is for me then. Thank you

29

By the way if someone is able to provide an alternative method to my original question I posted here I am still interested to hear it, thank you all

30

@phrase9 just as a thought experiment you should do some research and look for companies that are still “selling software packages” to download and install, and see if any of them resonate with your business model. Microsoft, Google, Steam, Adobe, and in the Construction world CoConstruct, ProCore, Bluebeam, STAFCK, Sage, Autodesk.

Very few of these are “pay once and download” because everybody has been down that hole before and they all have or want SaaS models. Everything you’ve described you can do in a model which shares a centralized app for lots of people, companies, etc. You can even limit features by permission roles, and create your app and database in such that only certain features are available to certain tiers. You can also create certain features which are “enabled/disabled”. You can either charge different tiers of recurring fees or you can charge a one-time fee for any particular “feature” of the app, or you can charge for “new version”.

These videos may give you some ideas -

It will take some planning and deep thought on how you develop this on Bubble, but the massive majority of software companies utilize this model, regardless of whether the software is a downloaded package or web based, and @mikeloc gives a very good example of the use case with the crowdfunding service. Fundamentally what you’re trying to do can work from a business model perspective, but the way you are thinking of building it is dated.

Hope that helps.

1 Like
31

Hi Chris

Thanks for your input. After making this post, I have in fact changed my mind and am going to go down the single database Saas route. I should thank @mikeloc first and foremost for changing my mind.

I joined Bubble about 3 years ago with the intention of creating a single database SaaS. But after encountering several off-putting posts at the time about how such apps weren’t scaling well on Bubble, I bought a Wappler license but found it too complicated to get into. I then decided to return to Bubble and simply sell ready made apps.

But it appears that time has passed by without me realizing I had developed tunnel vision. I am happy to now know judging from responses like yours and that of @equibodyapp that single database SaaS apps can work fine if built correctly.

32

Best of luck! I’ve built some stuff and then redesigned parts of the database for speed and scalability, but I think a lot of the problems people run into are from not planning and having to do advanced search queries and filtering (or trying to do too much on the front end), and the RDB aspect of Bubble is so fast, if the infrastructure is linked well, and you’ve run through the use case of how the data will be accessed, Bubble will be very performant. There are lots of little tricks that modern websites utilize to make stuff really fast.

2 Likes
33

@mikeloc @chris.s @equibodyapp

to all the good people who advised me to go the Saas route, would you consider my original idea worth revisiting considering Bubble’s new pricing scheme or do you still stand by the idea that Saas is the best way to go?

34

No, definitely not, in my opinion, and the pricing model (old, new, or something different down the line) has nothing to do with it.

35

@phrase9 I re-read your hypothetical situation, and maybe you’ve already implemented it to some degree, but it seemed to me you wanted to:

“Create an app where people can purchase it, and then run it on their own, and have hundreds of their own users”.

An example of this that comes to mind is loading a Discord like chat app. Someone “admins” the chat server, and then can have hundreds of users, which can have permissions, and do stuff. Obviously Discord is free, but I think that idea holds true. And my question around a use case like that, is do you want each person who wants to create their own Discord server to have their “own app”.

Bubble changed how some of their sub-apps work and you can read about it below, but the gist is that you have an app which is similar to what you’re talking about, but now you can be more nuanced about the client load. For instance, lets say one client only has 20 employees, you can run them on a lower ‘tier’ Bubble service on their own subdomain. “https://company1.chatservice.com”, and you can run “https://company2.chatservice.com” who has 5000 employees, but the same use case, on a different production plan, and charge them accordingly. But you’re fundamentally pushing the same app to both sub-apps, it’s all one app, and while their databases will be separate, the functionality is identical. In my opinion this is mostly for sub-domain (aka URL) and furthermore load balancing/easy calculating for pricing.

https://manual.bubble.io/help-guides/customizing-an-application/sub-apps

I agree with @mikeloc here - that unless whoever your client/customer is wants their OWN subdomain, which is something people legitimately want, I would generally not entertain subapps. And I certainly would not make “separate apps” where every time you implement something you have to copy it over.

Feel free to DM me if you are concerned about the privacy of your idea. But in general lots of people have very similar ideas, and the implementing and alignment to the customer is 90% of the success metric.