You don’t need to read code to evaluate code quality. There are signals you can check yourself, right now, with tools already on your computer. This guide is for founders who built their app with AI tools and want to know: “Is this actually ready for real users?”
Here are five things to check — and what to do about what you find.
Signal 1: Does the App Handle Errors Gracefully?
The easiest test: try to break your own app. Systematically.
What to try:
- Submit forms with missing required fields — do you get a clear error message, or does something crash?
- Click every button twice in rapid succession
- Navigate directly to a URL that doesn’t exist (e.g.
/dashboard/nonexistent-id) - Log out and try to directly navigate to a logged-in-only page
- Try the smallest and largest possible values in number fields
What good looks like: Clear, human-readable error messages. The app stays usable. You can correct the problem and try again.
What bad looks like: Blank pages. “Something went wrong” with no further information. Pages that don’t load at all. Errors that leave the app in a broken state requiring a page refresh.
Why it matters: In production, real users do all of these things accidentally. A blank page or cryptic error loses you a customer. Worse, some error states can expose unintended data or leave transactions in a half-complete state.
Signal 2: Are There Automated Tests?
Ask your AI assistant or developer: “Show me the test files.” Or look in your codebase for files ending in .test.ts, .test.js, .spec.ts, or a directory called __tests__ or tests.
What good looks like: A meaningful number of test files. Tests that run with a command like npm test. Tests that cover the core flows your business depends on — signup, payment, key user actions.
What bad looks like: No test files at all. Or test files that are all commented out. Or a single test that just checks 1 + 1 === 2.
Why it matters: Automated tests are the only reliable way to know that a change you made didn’t break something else. Without them, every deployment is a gamble. This matters more as you grow — a codebase without tests becomes harder and riskier to change over time.
The honest caveat: AI-generated code often ships without tests. This isn’t a crisis — but it is a risk that compounds. If your app is doing anything involving money, sensitive data, or user auth, the absence of tests is worth addressing.
Signal 3: Does It Load Fast?
Open your app in a browser and press F12 (or right-click → Inspect) to open DevTools. Click the Lighthouse tab (in Chrome) and click “Analyse page load.” Wait 30 seconds.
Lighthouse gives you a score from 0-100 for:
- Performance — how fast the page loads
- Accessibility — can all users use it
- Best Practices — common web quality indicators
- SEO — how well search engines can read it
What good looks like: Performance 80+. Any score under 50 indicates significant issues.
What to look for in the details: “Eliminate render-blocking resources,” “Reduce unused JavaScript,” “Serve images in next-gen formats.” Each item shows its potential impact in seconds.
The mobile test: Run Lighthouse on “Mobile” mode as well as “Desktop.” Mobile users on slower connections experience your app 2-3x differently than you do testing on your office wifi. Many AI-generated apps look fine on desktop and crawl on mobile.
Free alternative: PageSpeed Insights — paste your URL, no DevTools needed.
Signal 4: Are There Console Errors?
Still in DevTools, click the Console tab. Reload the page. Navigate through the main flows of your app.
What good looks like: No red errors. Possibly some yellow warnings, which are usually minor.
What bad looks like: Red error messages appearing as you use the app. Particularly watch for:
TypeError: Cannot read properties of undefined— a null pointer bugFailed to fetch— an API call silently failing401 Unauthorized— authentication gapsCORS error— backend configuration problemUncaught Error in promise— unhandled async failure
Why console errors matter: These errors are the app talking to you. Each one represents a user experience failure happening silently. The user sees a broken feature; you see the red text in DevTools that explains why.
Make a list of every red error you see. Each one is a bug to investigate.
Signal 5: Does It Work on Mobile?
Still in DevTools, click the device icon (top-left of the DevTools panel — looks like a phone) to enter responsive mode. Set the device to “iPhone 14” or similar. Navigate through your main flows.
What to check:
- Can you read all the text without zooming?
- Are all buttons large enough to tap? (44px minimum is the standard)
- Do forms work — keyboard pops up, form stays visible?
- Does the navigation work (hamburger menu if applicable)?
- Is any content cut off or overflowing the screen?
Why this matters: More than half of web traffic is mobile. AI tools often generate desktop-first UIs that work on a 1440px monitor and fall apart on a 375px phone. This directly affects conversion — a form that’s unusable on mobile loses you the mobile users who would have converted.
Interpreting What You Find
You found nothing alarming: Your app’s surface quality is good. This doesn’t mean there are no backend issues (security, performance under load, database indexing) — it means the visible layer passes basic checks. Worth getting a backend review before scaling.
You found a few isolated issues: Normal for AI-generated apps. Prioritise: console errors first, error handling second, performance third. Most of these can be fixed without a full audit.
You found widespread issues: Console full of errors, app crashes on basic actions, Lighthouse under 50, completely broken on mobile — these suggest systemic quality problems that run deeper than the surface. A professional audit is likely worth the investment before you scale.
When to Call a Professional
There are things you can’t check from the browser:
- Database security — Is user data properly isolated? Can one user see another’s data?
- Authentication security — Are tokens expiring? Is the auth flow vulnerable to brute force?
- API security — Are endpoints rate-limited? Are they accessible to unauthorised users?
- Scalability — Are database queries going to hold up at 10x current traffic?
- Secret management — Are API keys embedded in the frontend code?
These are invisible from the browser but potentially catastrophic in production. If you’re taking on paying customers — especially handling any financial transactions or sensitive personal data — a professional security and quality review is worth treating as a line item, not an afterthought.
The signals above tell you what you can see. A professional review tells you what you can’t.
Want a professional assessment? Get a free code review — we’ll look at both the visible and invisible layers, give you a prioritised list of issues, and quote a fixed price to fix them.