3 ms·

Its not a deal breaker, but it is a severe concern. For the following reasons that require me to trust you and become vulnerable to: Vendor / Platform Viabilit

by jlawer 5y ago

Its not a deal breaker, but it is a severe concern. For the following reasons that require me to trust you and become vulnerable to: Vendor / Platform Viability - If you shut down or deprecate your platform (looking at you google!) - I loose my application. Product Limitations - I have no other option besides re-write if you choose not to support something I need after I start using your platform. Are you investing enough to support me in the future? One of the reasons many GUI web editors let you get to the code, is that it provides an escape hatch if the included tools don't work and you need to fix a problem right now. Financials - What happens if you (or whoever acquires you) decide to do an Atlassian / Oracle and let me know my next renewal is 400% higher? Processes / procedures / options - By limiting things like code access you make it harder to find ways to fit weird corporate or regulatory requirements. I might be required to keep every version of my application's code for 7 years. You might make your platform hold the last 60 version of each file. I can't guarantee my auditors that I have every version of the code. As such I would be hesitant to do anything too significant in a No Code platform. On the other hand if the application is of minor significance (i.e. can easily be re-written) or temporary it would be acceptable. However the value of that code will vary by language. If your doing the magic in a very niche language then it will have less value then if it uses one of the mainstream 10 or so languages. Additionally if the code depends on services that are only offered by your platform, then again it will have reduced value as the lock-in is still there. Depending on strategy (especially around monetization) code exporting may not be viable for your platform, and the workarounds would take too long / too much resources. Now what that means is the tool needs to be SO GOOD at whatever niche it fits that it is a no brainer for me to put my concerns to the side and just try it if I need to work in that area. If your tool lets people save a heap / make money quickly while keeping quality up, it will speak a lot louder then the voice of reason worrying about long term supportability.

vishal_sahu 5y ago
Hi, thanks a lot for your detailed feedback. Appreciate it! Yes, some of the issues which you mentioned, came up from others also regarding building the complex feature or if the company is shutting down or getting acquired. Data residency issue came up with a fintech startup, which needed data locally in their country. The way we might have to plan is, to have the source code option available in one of the top 5 programming languages and that shouldn't be consuming our APIs/Services, so it have to be 100% detachment from the platform, otherwise it kills the purpose. To make it affordable/viable for us, we are planning to have a one time code export fee (so that people stick to the platform) and only choose that option when they want to do it for some reason like you mentioned above. The good thing is that we will have to be very very GOOD, so that the users stick to us. If they are not happy with the service, then they can leave the platform and host themselves (atleast they will not have to start from scratch) and may end up building complex applications with the aim to export the code if things aren't working out. One sideback i am seeing is that what is users are not able to use the code properly (everyone has their own coding standards) and then they might end up feeling frustrated and may need to do a lot of refactoring to make the code more readable in their standards. Non-tech people might find it much harder to use the code and we may have to end up providing the one time hosting/deployment service as well or find partners who can do so on our behalf, otherwise code export will be of no use for these non-tech users.

by jlawer 5y ago

vishal_sahu 5y ago

Hi, thanks a lot for your detailed feedback. Appreciate it! Yes, some of the issues which you mentioned, came up from others also regarding building the complex feature or if the company is shutting down or getting acquired. Data residency issue came up with a fintech startup, which needed data locally in their country. The way we might have to plan is, to have the source code option available in one of the top 5 programming languages and that shouldn't be consuming our APIs/Services, so it have to be 100% detachment from the platform, otherwise it kills the purpose. To make it affordable/viable for us, we are planning to have a one time code export fee (so that people stick to the platform) and only choose that option when they want to do it for some reason like you mentioned above. The good thing is that we will have to be very very GOOD, so that the users stick to us. If they are not happy with the service, then they can leave the platform and host themselves (atleast they will not have to start from scratch) and may end up building complex applications with the aim to export the code if things aren't working out. One sideback i am seeing is that what is users are not able to use the code properly (everyone has their own coding standards) and then they might end up feeling frustrated and may need to do a lot of refactoring to make the code more readable in their standards. Non-tech people might find it much harder to use the code and we may have to end up providing the one time hosting/deployment service as well or find partners who can do so on our behalf, otherwise code export will be of no use for these non-tech users.