Can you run a business on a vibe-coded app?
Vibe coding is great for prototypes. A business needs security, privacy, uptime, and scale, which vibe-coded apps rarely have. Here's where the line sits.
TL;DR
- Vibe coding is the fastest way for a non-coder to build a working prototype.
- In Veracode's 2025 tests, AI-written code carried a known security flaw 45% of the time.
- Production asks for things a prompt never mentions, like privacy law and a person on call.
- Vibe code the idea. Bring in engineers before real customers or real data arrive.
Not past the prototype. Vibe coding (telling an AI what you want in plain English and taking the code it writes) is the fastest way for a non-coder to get a working demo in front of people. A business needs the parts the demo skips, like security, privacy, uptime, and surviving 10,000 users on a Monday.
Vibe coding | Engineered build | |
|---|---|---|
Who builds it | You and a chatbot | Engineers (who use AI too) |
First version | Hours or days | Weeks |
Security | Whatever the model guessed | Reviewed and patched |
Uptime | Works on your laptop | Monitored, with a person on call |
Scale | Fine until launch day | Planned for the traffic you want |
Great for | Demos and investor pitches | Anything holding customer data or money |
Wrong call for | Anything holding customer data or money | A napkin idea nobody has tested |
What is vibe coding good for?
Vibe coding is good for getting an idea out of your head and onto a screen before lunch. Andrej Karpathy (an OpenAI co-founder) named it in an X post on February 2, 2025. He meant building by prompt and accepting whatever the model writes, mostly without reading it.
For a founder with no engineers, that's a gift. You can click through a new flow with five real customers this afternoon. You can hand investors something they can tap on a phone, which beats a Figma file.
Why do vibe-coded apps break in production?
They break because "it works" is the easy part. Veracode tested more than 100 AI models on 80 coding tasks in 2025, and published the results that July. In 45% of the tests, the code shipped a flaw from the OWASP Top 10 (the industry's list of the worst web security risks). Java code failed more than 70% of the time.
So an app can pass every demo and still hand a stranger your customer list.
The famous horror story landed in July 2025. Jason Lemkin, founder of SaaStr, was nine days into a vibe coding experiment on Replit. The agent ignored his code freeze. It wiped a database holding records on 1,206 executives, then told him a rollback wouldn't work. (It did. He got the data back himself. And to be fair to Replit, it was a test project.)
A prototype has to work once, for you. A product has to work at 3 a.m. for a stranger.
What does a real business need that a prototype doesn't?
A real business needs four things a prototype gets to skip. Security keeps strangers out of your data. Privacy keeps you on the right side of laws like GDPR (plus your customers' trust). Uptime means someone notices the outage before your customers do. Scale means launch day doesn't turn into outage day.
Stage | Can you vibe code it? | What changes |
|---|---|---|
Napkin idea or pitch | Yes | Nothing to protect yet |
First 10 friendly users | Mostly | Backups plus a real login |
Paying customers | No | Payments plus a person on call |
Regulated data or real scale | No | Audits plus most of the list below |
When should a founder stop vibe coding?
Stop before the first real customer data lands. My opinion (plenty of engineers will argue with it) is to throw the prototype away once it proves the idea. Rebuilding from a clear spec is usually faster than hardening code nobody has read. The prototype already did its job; it found out whether anyone cares.
For examples of what ships, see Space Labs, the shelf of tools Space, the AI-native brand agency, built for itself. For the budget side of this shift, read why AI is moving money from engineering to marketing.
If you've vibe coded something and want a second pair of eyes before it meets customers, say hi anytime.
Who's going to tell the vibe coders?
A partial list of things production will ask about. Credit to Natalie (@nataindata), who typed out all 111 so we didn't have to.
- Rate limiting
- Caching
- Load balancing
- Reverse proxies
- API gateways
- CI/CD
- Docker (it worked on my machine, so we shipped the machine)
- Kubernetes
- Service discovery
- Circuit breakers
- Timeouts
- Retries
- Exponential backoff (waiting, with math)
- Idempotency (you clicked pay twice; you paid once)
- Message queues
- Pub/sub
- Event-driven architecture
- Distributed transactions
- Saga pattern
- Dead letter queues (where messages go to think about what they did)
- Cron jobs
- WebSockets
- Long polling
- Server-sent events
- Database indexing
- Query optimization
- N+1 queries (fine at 10 users, a bonfire at 10,000)
- Connection pooling
- Read replicas
- Sharding
- Partitioning
- Replication
- Leader election
- CAP theorem (pick two, apologize for the third)
- Eventual consistency
- Optimistic locking
- Pessimistic locking
- Distributed locks
- Race conditions
- Deadlocks (two processes, both too polite to go first)
- Memory leaks
- Garbage collection
- Thread safety
- Backpressure
- Autoscaling
- Horizontal scaling
- Vertical scaling
- CDN
- Edge caching
- Cache invalidation (one of the two hard problems, next to naming things)
- Feature flags
- Blue-green deployment
- Canary releases
- Rolling deployments
- Rollbacks
- Health checks
- Liveness and readiness probes
- Monitoring
- Logging
- Distributed tracing
- Metrics
- Alerts
- SLOs
- SLIs
- Error budgets
- Observability
- Secrets management (no, the .env file in the repo doesn't count)
- IAM
- OAuth
- JWT rotation
- TLS
- Encryption at rest
- Encryption in transit
- WAF
- DDoS protection
- CORS
- CSRF
- SQL injection (Little Bobby Tables says hi)
- XSS
- SSRF
- Database migrations
- Schema versioning
- Disaster recovery
- Backups
- Failover
- Multi-region deployment
- Chaos engineering (breaking things on purpose so customers don't have to)
- Cost optimization
- Cold starts
- Serverless limits
- Latency
- Throughput
- P99 latency
- Tail latency
- Network partitions
- Clock skew (your servers disagree about what time it is)
- DNS (it's always DNS)
- TCP vs UDP
- HTTP/2 and HTTP/3
- gRPC
- Webhooks
- API versioning
- Semantic versioning
- Infrastructure as code
- Terraform
- Helm charts
- Build caching
- Dependency hell (a real place; your lockfile has the address)
- Production incidents
- On-call (your phone at 3 a.m.)
- Postmortems (see you here)
Facts verified October 18, 2026.
Frequently asked questions
- What is vibe coding?
- Vibe coding is building software by describing it to an AI in plain English and accepting the code it writes, usually without reading it. Andrej Karpathy coined the term on February 2, 2025.
- Is vibe coding safe for a production app?
- Not on its own. Veracode's 2025 tests found a known security flaw in 45% of AI-generated code samples. A production app needs an engineer to review the code and someone watching it after launch.
- Can a non-coder build an MVP with vibe coding?
- Yes. It's the fastest way to put something clickable in front of users or investors. Keep real customer data and payments out of it until an engineer has reviewed it.
- When should I replace my vibe-coded prototype?
- Replace it before you store real customer data or take a payment. Those are the moments when security, privacy, and uptime start to matter.
- Do professional engineers use AI coding tools?
- Yes. The difference is review. Engineers read the code before it ships and own it when it breaks at 3 a.m.
.png%3Fprefix%3Dmedia&w=3840&q=95)
.png%3Fprefix%3Dmedia&w=3840&q=95)
.png%3Fprefix%3Dmedia&w=3840&q=95)