Maintenance and security checklist for vibe-coded apps

Updated 2026-11-08

An app built with prompts still needs an owner for dependencies, access rules, backups and releases. Use this checklist to turn “it worked in preview” into repeatable evidence that the important parts still work after a change.

This checklist is for a JavaScript or TypeScript app in a public GitHub repository using npm, pnpm or Yarn. It applies whether the initial code came from Lovable, Bolt or a coding agent. It is a practical maintenance routine, not a security certification. The public dependency report at the end covers supported metadata; the rest needs application and backend checks.

Assign a named owner to each unresolved item. That can be you, a teammate or a maintainer you hire, but “the agent will handle it” is not an ownership record. Keep the evidence beside the change so a future reviewer can see what was checked and what was deliberately deferred.

Write down what you operate

Start with a short repository README section that someone else could follow. Record which repository and branch feed the deployment, the required runtime and package manager, and where the backend lives. Keep secrets out of the document; record where authorized maintainers obtain them instead.

Distinguish preview from production. A local app that uses a live database is not an isolated test environment. Before running a generated script, check its targets and whether it can send real emails, write customer records or trigger payments.

If Lovable is connected to the repository, confirm its current sync behavior in the GitHub integration documentation. Keep unrelated experiments on a review branch. The Lovable update guide and Bolt update guide cover their respective workflows.

Triage dependency updates and advisories

Review the dependency inventory regularly and after an important security notice. An outdated version and a known vulnerability are different findings. A package can be old without a published advisory, or current while a vulnerability remains unpatched. Record which kind of work you are accepting.

For an npm project, npm outdated reports installed, allowed and latest-tagged versions. Use the safe-update checklist to select a small package family. Follow the repository’s existing manager rather than creating a second lockfile.

For security notices, read the affected version range, the proposed fix and the package’s role in the application. Use the GitHub security-alert workflow to track decisions. If no fix exists, record the constraint and a reasoned next action. Do not dismiss a finding merely because it appears under development dependencies.

Keep major framework migrations separate from unrelated patches. They can require source edits, runtime changes and new deployment assumptions. A small review with an owner is easier to finish than a backlog of generated update pull requests nobody can explain.

Check access rules and exposed secrets

Test the app signed out, as an ordinary test user and as a second user with separate records. Confirm each role can do what it should and cannot read or modify another user’s private data. Check the backend response as well as the button visibility; hiding a control does not authorize a request.

For Supabase-backed apps, follow the RLS guide. Keep policies tied to the intended roles and ownership model. Administrative secret keys belong on the backend. A privileged dashboard view is not evidence that a browser user’s access rules are correct.

Review changes to authentication, row policies, storage access and privileged functions with extra care. Keep schema work in the migration workflow so the deployed database and repository do not silently diverge. Ask for an explanation of any broad access grant before approving it.

Inspect source changes and examples for credentials before publishing. If a secret appeared in a public repo, revoke or rotate it at the provider; removing the current line does not undo exposure. Check where that credential was used and update authorized environments. Avoid copying real records into public bug reports to explain a failure.

Verify backups and recovery

Write down what your backup actually contains, where it lives and who can restore it. Do not assume a source repository contains database rows or uploaded files. Keep a recovery procedure that an authorized person can follow when the original builder is unavailable.

Supabase’s backup documentation notes that database backups exclude the objects stored through the Storage API. Plan file recovery separately. Check your project’s actual backup coverage and retention rather than relying on a feature name from another plan.

Rehearse restores in an isolated destination with appropriate access controls. Confirm that the restored app can read what it needs and that restored data is not exposed to the public. A backup file you have never restored provides less confidence than a documented successful rehearsal.

Keep code recovery separate from data recovery. Lovable’s version-history guide says restoring code does not restore database data. A migration that removes a column needs a different recovery plan from a CSS change.

Test and review each release

1. Run the repository’s clean install, production build and existing focused tests.
2. Exercise a critical flow in a safe environment, including a failure or denied-access case.
3. Inspect the final source, manifest, lockfile and migration diff.
4. Record the tested revision, remaining limitations and person approving the release.
5. After publishing, check the intended version and the changed flow again.

Add a Playwright smoke test for a high-value path that lacks coverage. The test should assert an outcome, not just visit a URL. Keep the recovery checklist available when a change fails. Neither a dependency scan nor a browser test is continuous uptime monitoring or a complete application audit.

For weekly upkeep, you can manually create a recurring dependency-review task with Denly’s task schedules after connecting a project and runner. Configure its instructions and review gates before enabling it. The public report form below creates a report; it does not create a schedule or a pull request.

Commands and product behavior on this page were checked against the vendor documentation linked here on 8 November 2026. Those products change their screens. If a label has moved, follow the linked page rather than a memory of this one.

Read next

Handle Dependabot and GitHub security alerts in a small app · Software maintenance cost per year for vibe-coded apps