Repair a vibe-coded app or rebuild it? A practical decision test

A prototype that looks unfinished does not automatically need a rewrite. The useful question is whether its core behavior can be understood, tested and changed without repeatedly breaking something else. Start with the customer workflow that matters most rather than judging the number of generated files.

1. 01

   For a simple client portal, trace login, record creation and record retrieval. Identify where identity is checked, where the record is stored and which rule prevents another client from reading it. Write a small regression test around that boundary. If the path is understandable and the test can run reliably, repairing that slice may be a sensible first investment.

2. 02

   Next, separate cosmetic problems from structural ones. A confusing label, duplicated component or awkward loading state can often be fixed locally. Missing ownership checks, conflicting data models and business rules copied across several screens require a broader plan. List examples rather than describing the whole repository as messy.

3. 03

   Try one bounded repair before estimating the entire project. For example, make duplicate form submissions produce one record and verify the behavior under a slow connection. Record which modules changed and what other behavior needed retesting. This gives a more useful estimate than guessing from a screenshot.

4. 04

   A rebuild becomes easier to justify when the required workflow conflicts with the existing model or when no one can establish a reliable deployment and recovery path. Even then, preserve useful assets: customer terminology, accepted workflows, migration requirements and tests that describe the expected result. Rewriting code does not eliminate the need to understand the product.

5. 05

   Ask for a decision memo containing the repair scope, remaining risks, migration work and the evidence behind the recommendation. Compare the next usable release under each option, including interruption to existing users. The best route is the one that makes an important workflow dependable at an acceptable cost, with a clear way to check the result.