My thoughts on this differ from @daniel3 mainly because I decided to go the sub-app route despite the worries of scale. Yes, it could be a nightmare to manage 1500 sub-apps, but so far with our processes in place we’ve managed to launch over 45 sub-apps in the last few months and have plans to push over 100 more before the end of the year. So far it’s been fairly smooth sailing all due to routines, processes and habits built around managing the accounts and the people who are our customers. Launching 1500 sub-apps in a matter of weeks could pose a challenge (more on that below)
My reasoning/requirement for going the sub-app route was the ability for our customers to host on a custom domain name, including maintaining their own SendGrid account and video hosting account in Ziggeo. This simply wouldn’t be possible if we hosted each client in 1 app (it would be a stretch, esp with the custom domain consideration). Security improves a bit, but you still have to cover the basics like privacy roles on the database or it’s no better than hosting in a single app.
One other benefit of going the sub-app route is being able to view logs/stats/db/file storage on a client-by-client basis through their own Bubble dashboard. So far this has been extremely valuable, and I only expect it to get better on Bubble’s end. Bubble is growing with their client base. If a handful of their accounts scale to 1500 sub-apps and beyond, they will need to build tools to assist in managing this (whether it’s sponsored or not). You must be careful when you’re pricing your SaaS offering. Take every facet into consideration – all API usage, Bubble infrastructure (you’ll want to be on dedicated once you scale beyond a handful of beta accounts), human capital (the cost for you to manage an account), payment processing fees, etc. The list goes on obviously, but getting back to your questions:
There is no limit in terms of number of sub-apps, it is based on your usage of server resources. You could have 1 sub-app that use all $165 of your resources or 10 sub-apps that take up half of your $165 plan cost. Depends on number of users, workflow complexity, performance of your app in general, total pages loaded, usage of cached resources vs new resources, total number of live users creating workflows, how many recurring events and/or workflows and how frequent, etc. Again, pricing needs to be one of your top priorities: don’t tell too many people what your prices are going to be right away. You might find out each user costs you an average of $27/mo (seriously), so scale steadily and talk to your customers about their needs before signing them up. Launching a sub-app for us still costs us 30-60 minutes of our time, which is fine because we account for this cost in our package prices. If you’re trying to add on 1500 sub-apps per week, for instance, you most likely won’t be able to fulfill all the “orders” going the sub-app route. On another note: hosting and updating changes to sub-apps requires server resources too. You will not be able to support 1500 sub-apps at $165 even if the apps were all empty. 1 app can use 1-2% of an entry-level dedicated server’s resources at any one time. You will find that $1000/mo may be required to host and manage 25-50 active sub-apps if not more (and that’s just Bubble’s cost). This is why pricing and decision to go the sub-app route do require serious attention. You could shoot yourself in the foot pretty easily.
I’d estimate, considering reduced costs due to scaling, each sub-app will cost you $20-40/mo. I could be wayyy off here because I don’t know your app and how it functions, just know there is a real cost to providing each sub-app.