Vibe-Coded App Maintenance: What to Check First

The first maintenance task for a vibe-coded app is to prove that someone can change it safely. That means reproducing the running version, understanding where data lives, fixing a real problem, and recovering if the release goes wrong.

An app built with AI can be useful and maintainable. It can also become difficult to operate when the only record of its design is a long chat and the only debugging method is another “fix it” prompt. The difference is observable in the system and its working practices, not in whether a human typed every line.

If you own an AI-built product, use the following handover exercise before commissioning more features. It gives a developer or agency concrete evidence for deciding what to retain, repair, or replace.

What the maintenance debate gets right and wrong

In a widely discussed r/vibecoding thread, u/JFerzt argued that an impressive prototype can become painful when bugs and feature changes expose code its owner does not understand.

The replies strongly disagreed about whether that is inherent to AI coding. u/montdawgg described using documentation, incremental changes, logging, and commits to maintain their apps. u/bwat47 pointed out that undocumented architectural decisions create problems in human-written software too. Other replies claimed prompting alone could resolve the issue, without supplying evidence that would establish a general success rate.

Those are individual experiences, not a controlled comparison of development methods. The useful question is narrower than the argument: can your team explain, test, release, and recover the software it already has?

A maintenance review should answer that question. It should not begin by declaring the code worthless or by accepting a polished interface as proof that the underlying system works.

Start with the app's real commitments

List the things users rely on. For a customer portal, that might be seeing the correct projects, uploading a file, receiving a confirmation, and returning later to find the same information. For an internal tool, it might be assigning work without losing the previous owner's notes.

Write the expected outcome in business terms. “The upload component renders” is less useful than “the authorized customer uploads a file once, the assigned employee can open it, and another customer cannot.”

Include failures. What should happen if the file is too large, the user loses connectivity, or the storage provider is unavailable? A clear error and a recoverable draft may be correct. A success message followed by missing data is not.

This list becomes the basis for the handover test. It also prevents a review from spending all its time on code style while ignoring the transaction your customers actually need.

Establish ownership before touching the implementation

Confirm who controls the repository, domain, hosting, database, authentication provider, file storage, email service, and any other required integration. An app is not fully handed over if the business cannot access a production account without contacting its original builder.

Record the owner and recovery process for each account. Use individual access where supported and transfer credentials through an appropriate secure mechanism. A public setup document should name required environment variables, not contain their values.

Check whether the production deployment comes from the repository you received. A local folder can look complete while the live app was built from a different branch or an unrecorded manual change. Establish the deployed revision and the release process before accepting the handover.

Also list recurring operational responsibilities: account renewals, failed jobs, support requests, dependency updates, and backup checks. Ownership gaps often appear outside the application code.

Reproduce the running system in a clean environment

Ask the maintainer to set up the application from the written instructions without relying on the original builder's laptop. Use test accounts and isolated data.

The exercise should identify required runtime versions, dependency installation, database setup, migrations, environment settings, and the command that starts the app. Record anything the maintainer had to guess. Those guesses are documentation defects worth fixing during handover.

Then compare the test environment with production. Does it use the same authentication flow? Are scheduled jobs enabled? Does it call sandbox or live third-party services? Differences should be deliberate and documented.

A successful local page load is a useful first check, but not the finish line. Continue through the real user journey. The missing piece may be a background worker, a webhook subscription, or a storage permission that the frontend never reveals.

Use two accounts to test the boundary

For a multi-user app, create two controlled accounts with different records. Verify that each can access its own data and cannot read or change the other's data through normal application requests.

A hidden button is not an authorization rule. The server needs to enforce the decision when it receives the request. Include role changes and revoked access in the test: an employee removed from a project should not retain access through an old session or saved link.

These checks should be performed only on systems you own or are authorized to test, using controlled records. The purpose is to verify the product's intended boundaries, not to experiment against unrelated users.

For a formal security review, the OWASP Application Security Verification Standard provides a structured basis for requirements and verification. A short maintenance exercise does not establish compliance with that standard or replace a review appropriate to the application's risk.

Follow one transaction beyond the screen

Choose an important action and verify every resulting state. For example, a customer submits a request, the database stores it, an employee receives a task, and the customer sees a confirmation.

Check what happens when the request is repeated, interrupted, or partially completed. The browser may time out after the database write succeeds. If retrying creates another task and sends another email, the visible error has concealed a completed side effect.

Require a way to connect the user request with backend records and integration outcomes. Useful logs show which operation failed and which result was committed. Avoid recording passwords, private file contents, or full customer payloads merely to make debugging convenient.

This is where AI assistance can be useful: explaining unfamiliar code, identifying relevant paths, and proposing tests. The acceptance decision still rests on observed behaviour, not on the assistant's statement that it fixed the problem.

Prove recovery, including the database

A code rollback and a data recovery are different operations. Returning to yesterday's application version will not automatically undo a database migration or restore a deleted file.

Ask the maintainer to explain what a release can change and how each change is recovered. Rehearse restoring a backup into an isolated environment, then check representative records and relationships. A backup job marked successful does not demonstrate that the restored application can use the data.

For schema changes, identify whether the old application remains compatible with the new database. Some releases require a forward repair rather than a simple rollback. Record that before deployment.

Set recovery expectations around the business: how much recent work could be lost and how long the core service could remain unavailable. The appropriate design depends on those requirements. Do not substitute an impressive backup feature list for a tested recovery outcome.

Fix one representative bug as the handover test

Choose a bounded defect that crosses a meaningful part of the system. It should be real enough to reveal the workflow, without requiring an architectural rewrite to complete the exercise.

The maintainer should reproduce it, state the expected result, identify the cause, make a focused change, verify related behaviour, and release it through the documented process. Preserve the before-and-after evidence.

If this small change requires days of guessing, that is useful information. Identify whether the obstacle was missing access, unclear requirements, tangled code, unreliable tests, or an undocumented service. Each suggests a different improvement.

What the coding research says about speed

A 2025 METR study randomized whether experienced open-source developers could use AI for real tasks in familiar repositories. Across 16 developers and 246 tasks, the study found that allowing the early-2025 tools increased completion time by 19%, despite participants expecting a speedup. That result describes those developers, tasks, and tools. It does not establish that AI coding is slower in every setting. Original study

The newer context matters. In a February 2026 update, METR said its follow-up experiment gave an unreliable signal of the current productivity effect because of selection effects and difficulties measuring concurrent agent work. It changed its experimental approach rather than presenting the old result as a permanent verdict. METR's follow-up explanation

For an app owner, the lesson is to measure accepted work. Count investigation, prompting, review, testing, rework, and post-release corrections. Generated code volume is not a maintenance outcome.

Measure a completed change, not a fast draft

Consider a hypothetical fix that takes thirty minutes to generate, ninety minutes to review and test, and another hour to correct after release. The total effort is three hours, not thirty minutes.

That may still be an improvement over the alternative. To find out, compare similar changes with comparable acceptance criteria. Do not compare a small interface adjustment with a difficult permissions migration and attribute the difference to the coding tool.

Track recurring defects too. If the same area breaks after each feature, the team may need a clearer boundary, a better regression test, or a simpler design. Repeated prompting around the symptom can hide that work without eliminating it.

Time is only one measure. Include whether the change achieved the user outcome, preserved access boundaries, and left the next maintainer enough context to continue.

Decide between repair, replacement, and rewrite

Keep working software when its behaviour is understandable and the maintenance path is sound. Replace an isolated component when its interface can be defined and its problems are concentrated. Consider a wider rewrite when fundamental requirements cannot be met through a credible repair plan.

Ask a proposing agency to show that reasoning. “AI wrote it” is not a technical diagnosis. Neither is “the tests pass” if the tests omit the failing business process.

A rewrite also has migration work: accounts, records, files, integrations, and customer workflows must move correctly. The existing CRM data migration checklist illustrates why successful import messages can miss important losses. A replacement app needs equally explicit reconciliation for its own data.

Prefer a staged decision with evidence from the handover exercise. It gives you a basis for scope without paying to rediscover the same uncertainty during a rebuild.

Rehearse a routine dependency update

Maintenance includes changes your product team did not request. A library, runtime, or connected service will eventually require attention. Choose a low-risk update and ask the maintainer to show how they assess compatibility, read migration notes, test the relevant behaviour, and release it.

Keep the dependency lockfile and runtime requirements with the project. Document any intentional delay, including what prevents the update and who owns resolving it. Automatically accepting every update and indefinitely avoiding all updates are both poor substitutes for an operating process.

Use the exercise to check whether the environment is reproducible after the update. If the app works only because an old laptop contains an undocumented package version, the handover still has a gap. Fix that gap while the original setup is available for comparison.

Keep a short operating record

After handover, maintain a concise record of architecture decisions, release instructions, critical tests, known limitations, and incident resolutions. Explain why an unusual choice exists, especially when a later maintainer might otherwise remove it as unnecessary complexity.

Keep that record close to the code and update it when behaviour changes. A giant document that no longer matches the application is less useful than a small accurate explanation of the important boundaries.

AI can help draft and update the record, but the maintainer must verify it against the implementation. The goal is to make the next change easier to understand.

Your app is ready for ongoing development when someone can show how it works, fix a meaningful defect, and recover from a failed release. That is a concrete maintenance standard whether the original code came from an AI assistant, a freelancer, or an internal team.