23-Point Checklist for Vibe-Coding Apps Before the First Payment

Before your vibe-coding app accepts its first payment, ask an AI agent to check these 23 points:

1. A single design-system document exists, and all colors, font sizes, and spacing match it.
2. Separate screens are provided for each state: loading, empty, and error.
3. Private keys are stored only on the server. Frontend files and Git history are checked for leaks, and every key ever exposed is rotated.
4. Every API endpoint verifies authorization and access rights on the server. Row Level Security (RLS) is enabled in the database.
5. Usage-based services such as AI, SMS, and email have spending limits or alerts configured.
6. Payment webhooks verify signatures, and repeated notifications for the same payment do not cause duplicate accounting.
7. Refunds, cancellations, and failed charges are tested in test mode. Each scenario runs once and ends with the correct status.
8. Access is revoked on time after a trial or subscription ends.
9. When switching from test to production payments, production API keys and the webhook signing secret are reconfigured.
10. Monetary amounts are stored as integers in the smallest currency unit, as in Stripe. Do not use floating-point numbers: in JavaScript, 0.1 + 0.2 is not 0.3.
11. Double-clicking the submit button creates only one order.
12. Sales tax or VAT is configured for the countries where the product is sold.
13. Terms of use and privacy policy match how the app actually works.
14. Daily automatic backups are configured. The free Supabase tier does not include them, so upgrade to Pro or set up your own dumps. Restore into a new database at least once.
15. Every database schema migration has rollback SQL prepared. Migration and rollback are tested on a copy of production data.
16. Lists with more than 1,000 records are not silently truncated. By default, the Supabase API returns up to 1,000 rows.
17. Time is stored as timestamptz, and each user's timezone is recorded in a separate column so reminders arrive in local time.
18. Soft delete is used first, and RLS hides deleted records. When an account is deleted, the user's data is removed permanently.
19. Users can export their own data.
20. Names with apostrophes, emoji, or right-to-left text do not break input fields.
21. Images use WebP or AVIF formats, and content below the fold loads as the user scrolls.
22. Indexes are created for fields that are filtered most often. With dozens of test records everything may look fast, but real data volumes reveal slowdowns.
23. Error monitoring is connected so you learn about issues before your users do.

Send the full list to your agent and add this prompt at the end. The agent should check each item and present results in a table:

Distribute the check among five subagents by the following areas:

1. Design and performance.
2. Security.
3. Payments.
4. Data.
5. Post-launch operation.

Check all items without changing anything. For each item, indicate whether it passed or failed, and name the file where the problem was found.

If something can only be checked through a service dashboard, mark the item as «Requires my confirmation» and provide step-by-step instructions for manual verification.

Test backup and restore only on a test database, and payments only in test mode. Do not modify production data.

First show me the results table, and do not fix anything until I confirm.