Ask HN: Would you expect a NoCode Platform to give the code export? | Hacker News Reader

Ask HN: Would you expect a NoCode Platform to give the code export?

4 pointsvishal_sahu17 comments

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.

View on HN

The usual problem with no-code platforms is that the code they generate is garbage anyway and can't realistically be re-used or manually edited.

I'm addressing the doing things in code which can't be done in no-code aspect.

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.

Thanks for the meaningful insights.

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.

Why not let them run code in the backend? Obviously you wouldn't let them have access to everything, but you could allow them to write event responders or things like that, which run in a VM, which you control very tightly, and only give X cycles to per second, etc.

It could allow a whole lot more flexibility.

Actually we don't provision separate VM for each app, and they run in a shared environment with other Apps, so if the access is given to execute their code and if the code is consuming good CPU/RAM, then it can bring-down/affect other apps as well. Hence not seeing the option for them to execute their code.

But yes, if they want to write their code, they can always use AWS Lambda or similar services to execute their code and make an API call to pull/push the data from there and use them in the app by connecting it to that code via APIs.

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.

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.

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.

Thanks for your feedback.

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.

> What if the startup says that in case if it fails or shut down, it will make the source code public?

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.

>I don't know if marketing people will approve mentioning such a thing.

Thought to mention so that user know but no one will wait till that day or may be that day never comes.

> 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.

Yes, that the fear that although some people may have the confidence but majorly of them will not be able to do anything with that code.

We would plan to keep the price open so as to gain the confidence. The user will know that this is also an option going forward and they also know the price in advance, so that whenever they want to switch, then they know how much to pay. Obviously the price will be dependent on the plan and the app usage, so simpler apps will be cheaper to export and vice versa.

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.

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.

I think this should be pretty straight forward as there are generic algorithms to encrypt the password, not sure the case with bubble 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.

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.

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.

Yes, we do keep the versions of the software but if there are changes in the database layer (eg collection schema or validations, etc), then there is no point in restoring to the older version as it will bring inconsistency in the platform.

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.

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.

Cool. Thanks for your feedback. Planning to build this feature to gain confidence of people like you :)

Reply on news.ycombinator.com