Vibe coding vs. an MVP agency.

Most people reading this are not choosing in the abstract. They have a half-built app, a deadline, and a growing suspicion that the last few weeks have gone backwards. If that is you, the agency-versus-tool question is not the one to answer today.

The question that matters is how much of it you can keep, and the answer is almost never all of it or none of it. The screens you designed, the steps you put people through, and everything you learned from watching them are real and they are worth keeping. What usually has to be rebuilt is the foundation it all sits on, because the rules about who can see which data have to be right underneath rather than patched on top. Find out which is which before you commit to anyone, including us.

That founder posts about this often, so read the wording as a good description of the feeling rather than as evidence. The pattern underneath it is real though, and it is the single most expensive thing in this comparison. It happens in both directions.

Going cheap first, you buy a prototype for a few hundred dollars, spend four months at the point where it stops cooperating, and then pay for the proper build anyway. One founder wrote the arithmetic down after hiring the lowest bidder: $18K saved on the build, more than $40K needed to fix what that $18K bought. The detail that should worry you more than the number is that they could not find anyone willing to work on the result.

Going expensive first, you pay an agency to build a plan you had never tested, discover after launch that people wanted something slightly different, and pay again to change it. This is the older and better-documented version of the same mistake, and it is why building something rough and cheap first is genuinely good practice.

There is also a trap specific to fixing it yourself. Researchers tested what happens when you keep asking an AI to fix its own mistakes, and found a 37.6% increase in critical security holes after just five rounds of asking it to improve its own work. That study has not been through peer review yet, so hold it loosely, but the habit it warns against is exactly the one founders fall into at 2am.

A founder described the disappointment precisely: he expected a team that had spent years building software to bring him strong opinions about what the product should do next. Instead they kept asking him exactly what to build.

That is about how they get paid rather than how good they are. You are paying them to build, so if you keep bringing ideas they will ask questions, price them up, and deliver them. So the useful question in a sales call is not how fast can you ship this. It is tell me what you would cut from this list, and why. If the answer is that everything sounds important, you have learned something real about what you would be buying.