
Can you build production ready apps with vibe coding?
Probably the first thing experienced devs will say when they hear vibe-coding - "you can't use this in production" , let me break down what you can and can't do with vibe coding.
First things first, I wrote my first line of ANSI C in 2001 - so I can tell you, you must never vibe code in C. As you probably understood, some languages are pretty cool if vibe coded others not so much. I've tried vibe coding in the more popular languages I write code in - Python, JS, C and Rust
you can vibe code production ready apps in JS and Python, but..
you need to get your ducks in order. if you're a novice coder, please just don't - you're risking people's data and setting yourself up for some serious embarrassment. I've seen vibed apps that look 'well made' but don't allow you to login, they simply throw an error with every action. So, you need to understand the basics - even if it's in another language. But if you know what you're doing, here's what you need to do
for apps that will go on to have exactly 1 monthly active user, you won't know the difference
but for all other apps, you won't really get performance.
why?..
because you need to understand the bottlenecks for most web apps - heavy images, unnecessary full-page reloads, loads of unoptimised JS, non-pool executed db calls, absent cache, no job queues, badly configured protocols (but you probably don't have to worry about that if you're using Vercel/Netlify), bad/unknown JS libraries as dependencies, blocking calls and/or super slow db queries. These are just a few, there are loads more but the more I write here, the more I lose the general audience.
focus on getting your dependencies right..
The number one pain-point starting a vibe-code project is getting the dependencies right, sure why not just use "*" for every version - umm, chances are you LLM will call functions that were deprecated or invent new functions where none exist. The more you stick to things that are set in stone, the less headache you will cause.. which comes to the second step,
make sure you follow opinionated patterns..
This is probably the one thing I love about Ruby on Rails (even though I have never built an app in it) it sets all the patterns in stone (with a tad bit of flexibility) and for good reason. You don't need to reinvent Auth each time you write an app, you don't need to try using suboptimal data structures for high volume apps - there's a reason things are done a certain way, believe me - we did not have these things in 2002 and it was the wild west ... You had to worry about accidentally visiting a site with the wrong embedded script, malicious advertisers taking over your cookies, etc etc .. so things have evolved for a reason, and a lot of engineering effort has been put in to codify these patterns - so stick to them.
create component sets you can re-use across projects..
nothing beats tested components, if you're able to build reusable workflows for your app and verify their flow, chances are you will be fine (or not if you make an error in a component and repeat the error in the 50+ projects you're about to vibecode).
always use full stack frameworks for web apps..
Python is great for APIs, especially with Django-Ninja & FastAPI - but it's a headache if you're vibe coding in two languages simultaneously.
I love Python, and I've built production apps in it - but it's just much harder to recreate JS native features like hydration, ssr/csr switches and incremental page loading. Even with libraries like HTMX, it just because may more complicated. (HTMX is great though).
you need to be specific about what you want..
The thing about LLMs is that they are used to talking to loads of amateur devs (now more so), so if you just prompt make an app that does xyz .. you're setting yourself up for waisting your own time.
unless you're using something like Lovable where they already have a 200k word template fed in to the machine for you, but still manage to throw errors in every application -- kudos!! - that was my experience a few months ago anyway
I'm sure it's way better now, $100m later.
use thinking models..
They take up way more time and cost a lot more, but they are worth it. Normal models no matter how many params they use, they suck at code. They write over my code, change things that don't need to be changed, mess up existing flows and do a terrible job at debugging errors.
but hopefully all is well and you won't need to fall in to the same traps, as you can buy working vibe-coded projects on unloved and simply customise them to add the features or workflows you need, better yet you could hire an experienced coder through us to make those customisations for you.
so just to sort of summarise, you can use vibe-coding to build production ready apps but if you don't know the difference between a bitmap and a hashmap, please don't. Just use us :)