Scaling a vibe-coded MVP: when heavy operations blow up

· Published · 1 min read

Scaling on a vibe-coded MVP will kill your project.

A common example:

  • On your SaaS, a customer can run a heavy operation (say, purely by chance, reading a file with OCR and working on it with an AI)
  • For a prototype, the AI will often run the whole process in memory
  • The operation takes tens of seconds
  • You scale
  • You have more and more users
  • You add the option for a customer to run several operations in parallel

… everything blows up…

… and you don’t even know why…

… customers complain and churn goes up.

Why? One heavy synchronous in-memory operation on the server is fine… but when they pile up at the same time, it’s over.

Whereas a barely experienced developer would have set up a dynamic queue system to handle all of it.

The worst part is that this bug will very likely be hard to find, because the AI, unless you specifically ask for it, rarely takes it upon itself to add proper observability.

Queues and observability: two things I look at first in a vibe-coded app.