5 karma · joined March 9, 2021
How much "vibe coding" is already happening in production codebases right now?
Will we see a wave of mysterious, hard-to-debug technical debt in 2026–2028 from 2025's AI enthusiasm?
Is this self-interested marketing ("our tool is the safe way!"), genuine concern from someone who sees the LLM sausage factory up close, or both?
I am the Founder of DrapCode, a no-code platform to build custom web apps without writing any lines of code.
Introduction Video: https://www.youtube.com/watch?v=d7JWzFWHNuA
Quick Overview of the platform: https://www.youtube.com/watch?v=Bizu6v9k5Uc
It empowers non-coders/non-techies to build and launch full-fledged web applications without having the knowledge of programming. It also helps developers and digital studios/web agencies to quickly develop and deliver the web apps to their clients in a faster and cheaper way.
We are enabling users to build their custom web apps on DrapCode and if at any point of time they feel that they need better control on their apps, then they can host the apps on their infrastructure/servers, modify the code (if needed) and then continue their journey from there.
They will not have to start from scratch if they plan to move out for any reason. Infact, we will be going one step ahead and help them in migrating to the cloud platform of their choice.
Please feel free to ask any question or any feedback that you may have.
Happy to answer all the queries. Thanks!!
I am Vishal, Founder & CEO of DrapCode (https://drapcode.com)
We are building a NoCode platform to design, build and launch a web application without writing any line of code. Everything can be done visually by simple drag and drop builder and configurations.
We are providing the capability for DrapCode users to export their web apps (backend + frontend + database) completely and host it on their public/private cloud infrastructure and have a better control on them.
There are a lot of companies/enterprises who do not use any NoCode platform because of data security/privacy, scalability issues, regulatory issues or sometimes the incapability of the platform to provide the features which the user is looking for. In these cases the users have to discard the NoCode platform and have to build everything from scratch, so whatever effort, time, money etc they have invested in building their apps, gets wasted. This fear stops a lot of potential users to even try out a NoCode platform as they start feeling hostage by the platform and there is no way to come out. Currently there is no automated feature of data migration from one NoCode platform to another like it happens with CRM Softwares, HRMS Systems, Email inboxes, etc.
We are allowing users to build their web apps on DrapCode and if at any point of time they feel that they need better control on their apps, then they can host the apps on their infrastructure/servers, modify the code (if needed) and then continue their journey from there. They will not have to start from scratch if they plan to move out for any reason. Infact, we will be going one step ahead and help them in migrating to the cloud platform of their choice.
So basically we are helping them to go from NoCode to ProCode. We look forward to receiving your feedback on our work. Thank you!
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.
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.
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.
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.
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.
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.
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.