4 ms·

> 1. Are you planning to monetize? If so, what are some of your ideas? Yes, though my plan is not concrete, yet. I plan to offer a hosted version for teams wit

> 1. Are you planning to monetize? If so, what are some of your ideas? Yes, though my plan is not concrete, yet. I plan to offer a hosted version for teams with fewer technical members to be able to contribute the same way a front-end engineer would without self-hosting. This involves potentially hosting their app along-side the editor and creating friendlier abstractions on top of the git process such as creating branches, PR's, etc. Secondarily, I want to explore collaboration as a feature. The overall theme is to bring less-technical folks into the front-end. > 2. What is the grand scope for Studio? Short-term, I want styling to be very good. Then text content for copy-writing. Then structural changes such as reordering, inserting, and removing DOM elements. I want to keep it in the UI as much as possible since the surface area for logic is very large. I don't know if we can really be Webflow while letting users maintain full control of their code so if we have to compromise, I would lean more into giving control to the user instead of doing powerful features. Please let me know your thoughts on this plan, it is still in development :)

freedomben 2y ago
Nice, thank you! Yeah monetization is always tough, especially with something like this. My thoughts (were I in your position) would be to offer a full/unrestricted and open source single-player mode (open core model, with core licensed AGPLv3) that just modifies files on disk and is otherwise completely ignorant of git or anything else. Then for paid/hosted version, on top of it being hosted, you get full integration with github so PRs and diffs and things can be sent directly from the tool (which is great for designers). That also wouldn't require devs to do anything to buy in since the interface for them is just standard PR workflow. If it were me personally, I'd probably make the whole thing ("enterprise" features and all) open sourced under AGPLed with monetization being a hosted version available for paid stuff. Make sure you own the copyright so you can relicense in the future should that become necessary. I think you still get the vast majority of users that would be willing to pay that way, but you also get that crucial group of people who want the option of ejecting from you as a vendor should you go a directin they don't like (enshittification, etc). It's also IMHO a very ethical way to do business. Register trademarks on your app's name and stuff, and defend them proactively. Worst case scenario if someone forks and tries to compete with you, at that point you exercise that copyright to relicense the different parts to the "open core" model. It isn't likely to ever be an issue, but if it did you have a move. For targeting devs vs designers, IIWM I'd probably make the UI modal. I.e. design mode vs developer mode. Design mode can cater to designers, dev mode to devs. That way you can make UX decisions for one group that would irk the other group.
- hoakiet98 2y ago
  > Then for paid/hosted version, on top of it being hosted, you get full integration with github so PRs and diffs and things can be sent directly from the tool (which is great for designers) That's my impression too. Designers I know do not want to deal with the command line or git directly. I can't think of any products where that abstraction is done well (unless it's so good that I didn't notice). Thank you for the very in-depth take. We're figuring out monetization so this is very actionable + relevant.

freedomben 2y ago

Nice, thank you! Yeah monetization is always tough, especially with something like this. My thoughts (were I in your position) would be to offer a full/unrestricted and open source single-player mode (open core model, with core licensed AGPLv3) that just modifies files on disk and is otherwise completely ignorant of git or anything else. Then for paid/hosted version, on top of it being hosted, you get full integration with github so PRs and diffs and things can be sent directly from the tool (which is great for designers). That also wouldn't require devs to do anything to buy in since the interface for them is just standard PR workflow. If it were me personally, I'd probably make the whole thing ("enterprise" features and all) open sourced under AGPLed with monetization being a hosted version available for paid stuff. Make sure you own the copyright so you can relicense in the future should that become necessary. I think you still get the vast majority of users that would be willing to pay that way, but you also get that crucial group of people who want the option of ejecting from you as a vendor should you go a directin they don't like (enshittification, etc). It's also IMHO a very ethical way to do business. Register trademarks on your app's name and stuff, and defend them proactively. Worst case scenario if someone forks and tries to compete with you, at that point you exercise that copyright to relicense the different parts to the "open core" model. It isn't likely to ever be an issue, but if it did you have a move. For targeting devs vs designers, IIWM I'd probably make the UI modal. I.e. design mode vs developer mode. Design mode can cater to designers, dev mode to devs. That way you can make UX decisions for one group that would irk the other group.

hoakiet98 2y ago
> Then for paid/hosted version, on top of it being hosted, you get full integration with github so PRs and diffs and things can be sent directly from the tool (which is great for designers) That's my impression too. Designers I know do not want to deal with the command line or git directly. I can't think of any products where that abstraction is done well (unless it's so good that I didn't notice). Thank you for the very in-depth take. We're figuring out monetization so this is very actionable + relevant.