How to verify an AI-built app before launch

Ownership is a narrow, useful proof

Wantlist’s current ownership implementation uses a DNS TXT challenge. A builder places a token at a specified name, and the service looks for that exact token. A successful check demonstrates control over that hostname’s DNS at that time.

The implementation uses expiring challenges and expiring proofs. Changing the app’s hostname invalidates the relevant ownership evidence. This is separate from testing the app’s business logic, payment flow or security. Broader automated verification is still planned.

Test behavior with explicit acceptance criteria

For each feature claim, write a small test with inputs, expected output and a failure case. For example, a saved note should remain after reload, be visible to its owner and stay inaccessible to another account.

Ask the AI to help generate cases, but judge the result using the running system. Model confidence, a screenshot or a passing unit test is insufficient evidence for every hosted behavior.

1. Create two fresh accounts and test record ownership.
2. Try invalid, empty and unusually large inputs.
3. Reload after writes and confirm persisted state.
4. Test uploads and downloads under the intended permissions.
5. Repeat checks on the deployed version you plan to publish.

Use security requirements to define review scope

OWASP ASVS provides application security verification requirements that can inform a review. Select requirements relevant to your architecture and the data you handle, then record evidence against them. Linking to ASVS is not certification.

Give particular attention to authentication, authorization, secret handling, input validation and the ability to recover from failures. A sensitive application may need a specialist review beyond this launch checklist.

Make verification understandable to visitors

Publish a concise statement of what was checked, when it was checked and what the result covers. Distinguish builder-supplied claims from independently collected evidence. Avoid a single broad badge that implies more testing than actually happened.

An expired or revoked proof should stop being presented as current. A feature change may require a new functional test even when the domain proof remains valid. Keep evidence tied to the claim and version it supports.