An app that works for its creator can behave quite differently for a stranger. The creator knows which buttons to press, which inputs to avoid and which parts are unfinished. A new visitor knows none of this. These twelve checks cover the problems that show up most often when someone else opens an AI-built web app for the first time. Most take less than an hour to fix.
Before you begin
Run every check in a private browser window, signed out of all accounts. Use at least one device other than the one you built on. That is close to what a first-time visitor sees, and close to how a CESXY editor starts a review.
Check one: broken links
Open every link and button, including the footer, the navigation and links to outside pages. AI-generated code often leaves placeholder links or example domains that were never replaced. Make sure each one goes where you meant it to.
Check two: phone layout
Open the app on a phone. Text should be readable without zooming. Buttons should be easy to tap. Nothing should run off the edge of the screen, and the core action should work. If the app is not meant for phones, say so.
Check three: empty states
Look at what a visitor sees before entering anything: an empty list, a blank dashboard, a result area with nothing in it. An empty state should say what to do next.
Check four: error messages
Cause errors on purpose. Submit an empty form, upload a file type you do not support, paste a very long input and go offline mid-task. Each error should explain in plain words what went wrong and what to do. Raw technical errors and silent failures should go.
Check five: privacy note
Say what the app collects, how it is used, whether it is stored and whether it is shared. Include any AI service that processes what visitors type. The note can be short. It should be accurate and easy to find.
Check six: clear pricing
If any part is paid, show the price, how often it is charged and what it includes before you ask for payment details. If the app is free, say so. Unclear pricing is one of the quickest ways to lose a visitor's trust.
Check seven: loading and response time
AI features can take several seconds to answer. Show that work is in progress, and decide what happens when a response takes much longer than usual. A visitor who sees nothing happening will assume the app has failed.
Check eight: login
Decide whether a visitor really needs an account for the core action. If you can, let people try first. If sign-in is required, test it end to end, including password reset and sign-in with other services. Ask only for the permissions you need.
Check nine: usage limits and costs
If the app relies on a paid AI service, think about what happens when many people arrive at once. Set rate limits, spending caps or quotas where needed. A visitor who hits a limit should see a clear explanation, not an error.
Check ten: exposed keys
Make sure no API keys, secrets or access tokens appear in front-end code, page source or a public repository. AI-assisted coding can place keys in client-side code without you noticing. An exposed key can lead to unexpected charges or misuse.
Check eleven: a way to reach you
Give visitors a contact route, such as an email address, a feedback form or a profile link. People who hit a problem are more likely to tell you about it than leave if they can find you.
Check twelve: an accurate description
Read your headline and description again. Every claim should be true, real limits should be stated and the core action should be clear. This text becomes the basis of your CESXY submission. Editors compare it with what they find.
After the checklist
When all twelve are done, ask one or two people who have never seen the app to use it without help. Watch where they hesitate. Then submit it to CESXY. An editor will confirm the address and the core action, and record access, login, mobile needs and clear limits. An app that has been through this list is well prepared for that review.