Look at the screenshots to understand what the author means by 'product'.
The 100 hour gap between a vibecoded prototype and a working product
11–20 of 362 posts
Re: The 100 hour gap between a vibecoded prototype and a working product
#12>> people who say they "vibecoded an app in 30 minutes" are either building simple copies of existing projects, those are not copies, they aren't even features. usually part of a tiny feature that barely works only in demo. with all vibe coding in the world today you still need at least 6 months full time to build a nice note taking app . If we are talking something more difficult - it will be years - or you will nee…
What universe do you live in
Re: The 100 hour gap between a vibecoded prototype and a working product
#13I have had the experience with creating https://swiftbook.dev/learn
Used Codex for the whole project. At first I used claude for the architect of the backend since thats where I usually work and got experience in. The code runner and API endpoints were easy to create for the first prototype. But then it got to the UI and here's where sh1t got real. The first UI was in react though I had specifically told it to use Vue. The code editor and output window were a mess in terms of height, there was too much space between the editor and the output window and no matter how much time I spent prompting it and explaining to it, it just never got it right. Got tired and opened figma, used it to refine it to what I wanted. Shared the code it generated to github, cloned the code locally then told codex to copy the design and finally it got it right.
Then came the hosting where I wanted the code runner endpoint to be in a docker container for security purpose since someone could execute malicious code that took over the server if I just hosted it without some protection and here it kept selecting out of date docker images. Had to manually guide it again on what I needed. Finally deployed and got it working especially with a domain name. Shared it with a few friends and they suggested some UI fixes which took some time.
For the runner security hardening I used Deepseek and claude to generate a list of code that I could run to show potential issues and despite codex showing all was fine, was able to uncover a number of issues then here is where it got weird, it started arguing with me despite showing all the issues present. So I compiled all the issues in one document, shared the dockerfile and linux secomp config tile with claude and the also issues document. It gave me a list of fixes for the docker file to help with security hardening which I shared back with codex and that's when it fixed them.
Currently most of the issues were resolved but the whole process took me a whole week and I am still not yet done, was working most evenings. So I agree that you cannot create a usable product used by lots of users in 30 minutes not unless it's some static website. It's too much work of constant testing and iteration.
Re: The 100 hour gap between a vibecoded prototype and a working product
#14>> people who say they "vibecoded an app in 30 minutes" are either building simple copies of existing projects, those are not copies, they aren't even features. usually part of a tiny feature that barely works only in demo. with all vibe coding in the world today you still need at least 6 months full time to build a nice note taking app . If we are talking something more difficult - it will be years - or you will nee…
Can you expand on this? You definitely don’t need 6 months for a note taking app to be useable it is more you need to compete with the state of the art right
I'd argue you need between 6 minutes and 6 years.
It depends entirely on what you want. You can literally code a JavaScript 1-liner that will make a then put the content back in the URL and it will work serverless on pretty much any platform with a Web browser.
You can also write a note taking app that will be federated yet private, that will have its own scripting language, etc. I mean you can yak-shave your way to write your own OS or even designing your own CPU for that.
So... I'm not sure that metric, time, means much without a proper context, including who does it. It's quite different if to do that, regardless of the tooling used, if you are a professional developer, designer, fullstack dev, prototypist, PM, marketer, writer, etc.
Re: The 100 hour gap between a vibecoded prototype and a working product
#15>> people who say they "vibecoded an app in 30 minutes" are either building simple copies of existing projects, those are not copies, they aren't even features. usually part of a tiny feature that barely works only in demo. with all vibe coding in the world today you still need at least 6 months full time to build a nice note taking app . If we are talking something more difficult - it will be years - or you will nee…
You seem to be making the assumption that "app" means "sellable product", rather than "one off that works for me". It doesn't.
When everyone is able to make their own one off prototype in 30 minutes, no one will pay for the thing that took someone 6 months.
Re: The 100 hour gap between a vibecoded prototype and a working product
#16>> people who say they "vibecoded an app in 30 minutes" are either building simple copies of existing projects, those are not copies, they aren't even features. usually part of a tiny feature that barely works only in demo. with all vibe coding in the world today you still need at least 6 months full time to build a nice note taking app . If we are talking something more difficult - it will be years - or you will nee…
>with all vibe coding in the world today you still need at least 6 months full time to build a nice note taking app.
Bad example, note apps loaded with features are anti-productive and are for people who treat note taking as a hobby itself.
You have Obsidian anyway if you want something open source to work with.
Re: The 100 hour gap between a vibecoded prototype and a working product
#17[dead]
Re: The 100 hour gap between a vibecoded prototype and a working product
#18[dead]
Re: The 100 hour gap between a vibecoded prototype and a working product
#19Look at the screenshots to understand what the author means by 'product'.
This would have been generic slop if it wasn't for AI.
Re: The 100 hour gap between a vibecoded prototype and a working product
#20With sufficiently advanced vibe coding the need for certain type of product just vanishes. I needed it, I quickly build it myself for myself, and for myself only.
I built a jira with attachments and all sorts of bells and whistles. Purrs like a kitten. Saas are going extinct. At least the jobs that charged $1000 a day to write jira plugins.
Some minor UX enhancement SaaS of the most recent VC-funded wave will do. Maybe those who forgot how to invest in R&D and spent last 20 years just fixing bugs. There’s plenty of SaaS on the market that offers added value beyond the code. Data brokers. Domain experts, etc. Even if homemade solution is sometimes possible, initial development costs are going to be just one of several important factors in choosing whether to build or to buy.