Hi guys, we are building a NoCode Platform for Web apps and in the initial feedback, few of our initial users have asked that if they can host the application themselves in their infra. Reasons could be due to data localisation issue or scalability/security issues or may be they want to modify things later which cannot be done in the NoCode builder itself.
So just wanted to ask the community, is this something which can be a deal breaker for you if you have to use any NoCode Platform.
I'm addressing the doing things in code which can't be done in no-code aspect.<p>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)<p>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.<p>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.<p>Change a listbox to a combobox, you can still access the data in it, for example.<p>You can rename GUI elements, and rename them, and the code gets renamed to match. Two way flow between Code/NoCode is amazingly powerful.<p>There's a slightly buggy version of Delphi that lives to this day, called Lazarus.<p>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.
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:<p>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.<p>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.<p>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.<p>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.
For me, it's important that my applications will keep running long enough. I can't bet on a SaaS nocode startup if I have to throw away everything when the startup fail or is bought by a competitor.
The main reason I'm not going with Bubble is because I can't transfer users should I make another site, because of how password hashing works.<p>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.
It's not that I expect a NoCode tool to give me the code, it's more that I'm used to having software under version control.<p>So if I use your tool how to I handle change management?<p>Wether or not your app needs to be deployed on-site, kind of depends what your target market is and what it does.
If was running a business I would insist on it. I would be okay with paying for services but I would never allow any one service to be able to shut my business down if I could at all help it.