Yes, thats’s what we have in mind. We would put this on the production plan though, this is definitely a professional/reseller-type feature.
jejejejejejeje… yep, obviously, worth every cent I’d say.
Also, the apps would be editable, but as you push new changes, these changes would be lost.
I think this is a great idea. Thumbs up. Might have to upgrade to the next tier soon. So can you give us a clue as to the next big feature;)
here some thoughts I have with this feature according to my app (B2B2C type = SELLERS use my app with their own customers) and technical issues linked to it.
white-labeling
Ideally, I would sell to sellers a full white-label tool. So ideally it means :
- custom domain
- custom logo
- email sent with their company name and not mine.
Creating a child app, these things can be changed in the app settings so it would work I guess
For being a complete white-label solution, I would have to create a new app in developer.facebook.com, in my console on Google, etc. So when a user signs up, he grants access to the seller and not to my company.
So plugin key API would be define for each different app ? or it would only be master app ?
I just see a limitation with Stripe since I can only use my Stripe account without defining different public onfo for each app. I mean that the checkout popup would open with my company logo and not the seller one. So I don’t see how I build a white-label here.
####apps dependency
you mean that when pushing a new version to live - only the “linked” child app would be modified ?
personally I don’t think I would from time to time cut or link again some child apps. Changes would be for all the app without any exception at once.
####push modification
You mean pushing the design only ? not the app settings ?
####database
If the database is completely separate for each app, it would be difficult for me to use it. I would prefer to keep a single database shared between all the apps. Why ?
- I’ve got two tables for app config with all the different states of the app (so important !), text signatures, text describing some parameters, etc. It would be crucial theses tables are always up-to-date for every child app.
- when pushing changes to the live version, patches are usually necessary for updating/correcting the existing data. it would a bit painful to run these patches on every child app one by one.
And if separate database are the only way to do it. Can’t some tables be shared among the apps ?
####managing child apps
Also, being able to define tables shared among the app, every new child app created would refer to the UNIQUE ID of a table in the master app. For instance I would have a table SELLER and each child app would be for one SELLER. Thinking about it, I think it’s nice idea, like a “Thing” would be defined at the child app level.
The bubble team must have the worst headache trying to balance functionality with simplicity!
So what I have in mind is
- logo, favicon, domain (hence email) aren’t copied from parent to child
- each app has it’s own keys for plugins.
- the db would be separate
This could be the killer feature for Bubble, even greater tha responsive design, in my opinion.
The possibility to emulate all the great apps out there is king:
Client goes to the sign page (master app).
In the sign up it creates a new account (child app) - copies the same app from master, but with a new db
Client has its admin page, so it can customize it (logo, keys, domain etc)
If the client goes away, just delete the child app.
When you update the master app, just deploy and all child apps are up to date too.
Any good Bubble app could be SaaS online right away - just like Mailchimp, Google Docs, etc!
Great
To be manageable, could child apps have parameters defined in a master app table ?
Using this feature, my startup would worth only if I get several dozens of child apps. To manage them, the way I see it is that a table of APPS is created in the database, so we can link each app to a Thing. In my use case, each child app = one seller.
Would not be possible to choose either to have separate ddb, either keeping one single database ?
My app is built such as almost every element has a unique SELLER as the top parent Thing (kind of cascade model). So on production, performance would be slightly affected by ddb size and I would definitely prefer this second option. Other guys, if you are interested by this feature haven’t your design your ddb such this way ? I dealt with security concern thanks to Privacy rules and it works great . I mean no need to split the ddb for this reason. Other advantage : much easier to maintain.
Sorry if I get boring but I would lost a great opportunity here !
@emmanuel as you see it, “creating a new app” is an action a user could do, or it would be done by us (admin) ?
I love where this discussion is headed. I would pay for such a feature as I have a potential need for this as well.
I’m in on this as well… This will be an awesome feature!
I can see the multiple DB becoming a nightmare to manage. Rather than pushing child apps, why not simply allow bubble to respond to sub domains and leave it up to the app creator to manage this. If you wanted to make this easier you could have a specialized field called domainid that when added to an entity and an entity is created, deleted or searched for bubble automatically adds this as a restriction or allows the developer to determine whether to restrict by this or not. This way the designer can have full control. A true multitenant application instead of creating separate apps. One reason this approach is better because you need to think about mobile as well. You’re not going to want a different mobile app for each client. The one addition I would make to this is to allow for styles to be defined at the sub domain level so that the application could be styled based on the domainid and you don’t need conditional logic scattered throughout the application. I would also define the logo at the domain level so that this could be referenced using a specialized element. Just my two cents. I’d hate to see the proliferation of apps when multitenant saas is the way to go…
Just refine my view -
App Childs should just run on live mode. There’s no sense in give dev access.
Master app needs the emulated dashboard for the settings clients wants. As any SaaS out there - limit access, add as requested.
And the db must be separated, it will be a nightmare to merge all the data. Why a brand new client needs to get his data from a giant 5 years old terabit DB?
don’t you have a config table with different states (refused, approuved), catégories, type access, etc ?
if yes, how could you manage them on every child apps if ddb are separated ?
Exactly the same actual behavior, when you add or change something in your app and deploy it, all child apps will be updated.
Creating a child app should be available to the master only, manually and by workflow action, so the user can create by itself automatically (ex. Button create an service account)
It would be done by the admin. We’re not at the point where we can make this automatic for users. We could allow that later, but that will become an issue for the production plan, as it’s only 15 apps right now.
If it’s shared db, i really don’t see why we need more than one app. You just need to make the styling of the page, logo, etc dynamic so that it’s customized to the user.
I understand. Unfortunately, for now, it removes the automated, self service feel. I’m certain it have its place in a near future.
I’m very glad the evolution path Bubble is going. The team’s feedback to customers requests is very clear and quick. One of the nicest place to be online now.
Ps- I think enterprise plan could have it?