I'm old, so allow me to bring into the present an old no-code tool from the past. (It's priced itself into irrelevance in the present)
Delphi was one of the best no-code platforms I ever encountered. It allowed you to do a lot of no code-things, like set up a GUI, etc... but also allowed you to write code that interacted with that GUI, handles events etc.
The key thing is that the objects in the GUI all have properties that can be set in the GUI builder, AND interacted with in code. Changing one doesn't usually break the other.
Change a listbox to a combobox, you can still access the data in it, for example.
You can rename GUI elements, and rename them, and the code gets renamed to match. Two way flow between Code/NoCode is amazingly powerful.
There's a slightly buggy version of Delphi that lives to this day, called Lazarus.
If your tool can support complexity in the code, while letting the user keep changing the GUI, business rules, whatever in the no-code. You'll have given them far more power than almost anything else out there.
The challenge we are seeing here is that we are not generating the code on the fly (both way sync like you mentioned in Delphi) as we are also hosting the application on the SaaS cloud along with several other users apps and a lot of code will be clubbed/shared between the several layers.
Users will be able to add the frontend/GUI code but we don't allow them to execute the backend code in our environment (only the code written by our backend team will be executed in our environment, like other NoCode platforms)
Once they ask for an code export, then we will generate a code on the basic of their project, do some configurations changes so that it can run as a standalone app and then pass on that generated code to the client/user so that they can host it themselves or modify it to meet their specific/complex use case which might not be possible on our NoCode platform. Once they have exported the code, they cannot import it back. Its one way export only.
It could allow a whole lot more flexibility.
What if the startup says that in case if it fails or shut down, it will make the source code public? Even in that case, it will be quite tedious and challenging to host the application due to its complexity.
Will you be willing to spend some bucks (like 6/12 months subscription fee in exchange of the code?) so that there is no forced-commitment/attachment with the platform and you can host it yourself as and when needed.
We are planning to charge around $25 - $250 per month, depending on the traffic volume. All features will be available in all the plans.
I don't know if marketing people will approve mentioning such a thing. And yes it's a big project to adapt a SaaS platform to self hosted or on premise. I don't see that happening after the death of a startup.
Paying more to get the source code could work. But in my personal case, I usually have small projects and a fair pricing is necessary. When I see a "contact us" price to do on-premise in SaaS for example, I don't even bother to contact and I look for something else. I can't afford it if I have to ask about the price.
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.
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.
Otherwise everything else about it works fine. The nature of no code is that it scales terribly; it's often the best choice if you're building something in 10 hours, but bad if you have 1000 man hours. Code is code because it's the most efficient way to communicate. Startups are often willing to stick with it for a very long time though.
Since startups are willing to stick with the code for the longer duration, so sometime they have fear that what if the platform is not able to handle/provide what they are expecting and hence (a lot of times) decide to keep things in their control from the beginning by coding it themselves or use some open source framework, so that they can have better control going forward (what i think). Hence code can pay a major role in building the confidence. Not sure what could be the other challenges hence gathering feedback.
So if I use your tool how to I handle change management?
Wether or not your app needs to be deployed on-site, kind of depends what your target market is and what it does.
For all the UI changes, you can have as many versions as you want and can always revert back to any older version.
On-site deployment can happen only when you are able to extract the code and host it on the clients machine/cloud. The price point we are looking at ($25-$200 per month) will not make it us a viable option to manage the third party infra. Hence thinking to build it in a way so that the user can take the code and host it themselves, but then they cannot import it back in the builder/our platform.
