4 ms·

Well, the big issue with any of these is that you invariably find yourself needing that one feature so badly. "Here is your site!" "Great, let's add authentic

Well, the big issue with any of these is that you invariably find yourself needing that one feature so badly. "Here is your site!" "Great, let's add authentication." "Cool, do you want to login with Google, Twitter or Facebook?" "Github..." "Ooh, add it to the list..." And then you're waiting. This doesn't just happen once, it happens constantly on all kinds of things you need. This way you can go in and change it around. You already have a nice CSS pattern, you just drop it in.

beaconstudios 10y ago
oh hey, I just realised it was you - I tweeted you about getting in touch previously. Yeah this is a big focal point for v1 - providing an avenue for developers to write in any features that aren't natively provided in the editor. I'm currently playing around with a "code view" that shows you the compiled, unminified version of whichever component you're working on and allows you to modify it directly. The plan is to save those modifications as a diff that can be re-integrated when the component is built. Obviously it's not quite as simple as that but my hope is that the editor will be able to gradually add new workflows for missing features but without constraining developers.
- startupdiscuss 10y ago
  Looking forward to playing with it. One thing everyone wants to avoid is lockin. I have the feeling now that if AWS raises prices, I can go to Azure. If Postgres adds some new RestFul feature, I can switch to it. If I have to use your solution for the long term, and you are charging for it (which, of course, you should), I don't want to be bound to that solution forever. What if you sell the service and the buyer shuts it down?
  - beaconstudios 10y ago
    Yeah I totally agree - in no way should your company's software be dependent on the continued existence of my service. My thinking on this is that the service I'm offering needs to be sliced up into opt-in units - $X/month for the builder, cost-plus for hosting and scaling, gateway fee for ecommerce and so on. That way, companies that want to scale out can mix and match the offering as they choose. I am somewhat concerned that someone could build most of their app and then export the code and cancel, but as I'm still building out the MVP I'll leave that for later :)
    - startupdiscuss 10y ago
      Don't be afraid of that, you should be happy to have that as a service and encourage some people to do that if they want. I think 98% of the people will end up exporting their code and not using the service. It will be free. But it will make your service famous and the few people who do pay will be loyal. You can't do everything well. If the main thing you do is an MVP producing service, that is great. Add on to that. You might end up adding a whole different set of services such as paying for user feedback or user analysis or something else. Edit: Just to be clear - I don't mean to advise you on what the service should or should not be. I just mean that it will evolve in ways you may not anticipate. The market will pick and choose what it wants. The things you initially think are small might turn out to be more profitable than the things you initially think are big.
      - beaconstudios 10y ago
        I'm not really aiming for an MVP service in the long run though - I want to enable people to scale out their idea into a full product without having to export and start coding. I also don't think I would be keen to build this as a completely free (or effectively free) service, as this is going to be a big project and I want to scale it out into a business. I don't want to lock in users either though, so I'm aiming to find a good point where the product provides enough value that users would prefer to keep using it over exporting and coding.
onvel 10y ago
Bubble has an API connector that allows to connect to various third party APIs and integrate them into your app (including Github, Spotify, Banking etc). They also opened the possibility for users to create custom plugins with visual elements and workflows using JS code, so that changes the game completely... Although you still can't take the code outside of Bubble, it looks very attractive to build an MVP or even full blown product there.

beaconstudios 10y ago

oh hey, I just realised it was you - I tweeted you about getting in touch previously. Yeah this is a big focal point for v1 - providing an avenue for developers to write in any features that aren't natively provided in the editor. I'm currently playing around with a "code view" that shows you the compiled, unminified version of whichever component you're working on and allows you to modify it directly. The plan is to save those modifications as a diff that can be re-integrated when the component is built. Obviously it's not quite as simple as that but my hope is that the editor will be able to gradually add new workflows for missing features but without constraining developers.

startupdiscuss 10y ago
Looking forward to playing with it. One thing everyone wants to avoid is lockin. I have the feeling now that if AWS raises prices, I can go to Azure. If Postgres adds some new RestFul feature, I can switch to it. If I have to use your solution for the long term, and you are charging for it (which, of course, you should), I don't want to be bound to that solution forever. What if you sell the service and the buyer shuts it down?
- beaconstudios 10y ago
  Yeah I totally agree - in no way should your company's software be dependent on the continued existence of my service. My thinking on this is that the service I'm offering needs to be sliced up into opt-in units - $X/month for the builder, cost-plus for hosting and scaling, gateway fee for ecommerce and so on. That way, companies that want to scale out can mix and match the offering as they choose. I am somewhat concerned that someone could build most of their app and then export the code and cancel, but as I'm still building out the MVP I'll leave that for later :)
  - startupdiscuss 10y ago
    Don't be afraid of that, you should be happy to have that as a service and encourage some people to do that if they want. I think 98% of the people will end up exporting their code and not using the service. It will be free. But it will make your service famous and the few people who do pay will be loyal. You can't do everything well. If the main thing you do is an MVP producing service, that is great. Add on to that. You might end up adding a whole different set of services such as paying for user feedback or user analysis or something else. Edit: Just to be clear - I don't mean to advise you on what the service should or should not be. I just mean that it will evolve in ways you may not anticipate. The market will pick and choose what it wants. The things you initially think are small might turn out to be more profitable than the things you initially think are big.
    - beaconstudios 10y ago
      I'm not really aiming for an MVP service in the long run though - I want to enable people to scale out their idea into a full product without having to export and start coding. I also don't think I would be keen to build this as a completely free (or effectively free) service, as this is going to be a big project and I want to scale it out into a business. I don't want to lock in users either though, so I'm aiming to find a good point where the product provides enough value that users would prefer to keep using it over exporting and coding.

onvel 10y ago

Bubble has an API connector that allows to connect to various third party APIs and integrate them into your app (including Github, Spotify, Banking etc). They also opened the possibility for users to create custom plugins with visual elements and workflows using JS code, so that changes the game completely... Although you still can't take the code outside of Bubble, it looks very attractive to build an MVP or even full blown product there.