You can trust AI-generated code about as much as code from a fast, capable new developer: it is often correct, sometimes subtly wrong, and never a substitute for checking the flows that matter to your business. The Fanann Agent tests what it builds as it goes, but you should still walk through payments, sign-in and permissions, data access, mobile and RTL layouts, and your backup and rollback plan yourself before launch.
- how to test an app before launch
- testing ai generated code
- can you trust ai written code
- app launch testing checklist
Why AI-generated code still needs testing
Modern AI builders write working code quickly. They follow common patterns, use well-known libraries and rarely make the typo-level mistakes humans do. That is exactly why their mistakes are easy to miss: the code looks clean, the screens look finished, and the problem only shows up when a real customer does something slightly unexpected.
The issue is rarely that the AI cannot code. It is that the AI does not know what you did not tell it. If your prompt never mentioned that a coupon cannot be combined with another offer, or that a clinic receptionist must not see payment details, the model fills the gap with a reasonable guess. Reasonable guesses are not always your rules.
| Where AI code commonly goes wrong | Example |
|---|---|
| Unstated business rules | A discount applies twice because nobody said it should not |
| Edge cases | An order at 00:15 is rejected because opening hours cross midnight |
| Permissions | A regular user can open an admin page by typing its address |
| Payment states | An order is marked paid before the payment provider confirms it |
| Arabic and RTL details | Icons point the wrong way or mixed Arabic and numbers break a line |
| Plausible but wrong logic | A total rounds differently from your invoice, by one halala |
AI removes the typing, not the thinking. Someone still has to decide what correct means for your business.
How the Fanann agent tests as it builds
The Fanann Agent does not just generate files and stop. Like other AI agents, it works in a loop: it plans a change, writes the code, runs it, checks the result and fixes what fails before reporting back. That loop catches a large class of problems automatically.
- Code that does not build or has type errors
- Pages that crash or fail to load
- Main flows that break after a change
- Obvious errors in the console or server logs
- Re-checking earlier features after new edits
- Whether the business rules match reality
- Who should be allowed to see and change what
- Whether prices, taxes and totals match your invoices
- Whether the Arabic copy sounds right to your customers
- What should happen when things go wrong
Before we launch, list every user flow in this app (customer, staff, admin) and the scenarios you tested for each. Then test these additional cases and tell me the result: payment fails or is cancelled; the customer refreshes during checkout; a staff user tries to open an admin page; a customer tries to view another customer's order by changing the ID in the URL; the cart contains an item that just went out of stock. Fix anything that fails and summarize what you changed.
Try it in FanannFunctional and payment testing
Start by walking through the app as each type of user, on a phone, from first visit to final goal. Write the flows down so you can repeat them after every major change. This list becomes your personal regression test.
- 1Map the critical flows
Sign up, sign in, the main action (order, booking, enrollment), payment, and what admins do with the result. Usually five to ten flows cover what matters.
- 2Run the happy path
Complete each flow with normal, valid data and confirm every screen, email and notification.
- 3Try to break it
Empty fields, very long names, Arabic and English mixed, double-clicking submit, the back button mid-flow, slow network.
- 4Check the data
Open the admin side and confirm the record was saved correctly, with the right status, amount and timestamps.
Payments deserve their own pass
Most payment bugs live outside the happy path. Use your provider's test mode and cover every state, not just a successful charge. Our guide to local payments explains how methods like mada, Apple Pay and buy-now-pay-later options behave.
- Success: the order is marked paid only after the provider confirms it, ideally via a webhook.
- Failure and cancel: the customer sees a clear message and the order is not marked paid.
- 3-D Secure: the bank verification step completes and returns the customer to the right page.
- Refunds: full and partial refunds update the order and any related stock or loyalty points.
- Duplicates: a double click or retried webhook does not create two charges or two orders.
- Amounts: totals, VAT and delivery fees match what your invoice or accountant expects.
Authentication, permissions and security basics
Authentication answers who someone is; permissions answer what they may do. AI-built apps usually get sign-in right, because it follows standard patterns. Permissions are where your specific rules live, so they need deliberate testing.
| Check | How to test it yourself |
|---|---|
| Each user sees only their own data | Sign in as user A, copy an order or profile URL, sign in as user B and open it |
| Roles are enforced on the server | As staff, try admin URLs and actions directly |
| Sessions end properly | Sign out, press back, and confirm private pages do not reload |
| OTP sign-in resists abuse | Request codes repeatedly and confirm there is a limit and a cooldown |
| Secrets are not exposed | Confirm API keys live in project settings, not in page source or the repository |
| Inputs are validated | Enter scripts, very long text and wrong types in forms and check they are rejected or escaped |
| Data is private by default | Check that file uploads and storage links are not publicly listable |
If your app handles personal data in the Gulf, also read our overview of data residency and personal-data laws, and review the trust and security page for how hosting is handled. For legal obligations, always check the official source or a qualified advisor.
Performance, mobile and RTL checks
Most of your customers will arrive on a phone, often on mobile data. Test there first. A page that feels instant on office Wi-Fi can feel broken on a crowded network.
- Load time: open key pages on a mid-range phone using mobile data and note anything that takes several seconds.
- Images: product and menu photos should be compressed and sized for mobile.
- Lists: pages with many records should paginate or load progressively rather than all at once.
- Forms on mobile: phone fields open a numeric keyboard; nothing is hidden behind the keyboard.
- Small screens: test on a narrow phone; no sideways scrolling, no cut-off buttons.
RTL and Arabic content
Arabic-first apps need their own pass. Check that the layout mirrors correctly, that directional icons such as back arrows and chevrons flip, and that mixed content like phone numbers, prices and English brand names inside Arabic sentences display in the right order. Switch languages mid-flow and confirm nothing resets. Our article on Arabic-first UX lists the most common RTL mistakes.
Review every page in Arabic and English at a 360px wide phone screen. Fix any horizontal scrolling, cut-off text or buttons, icons that do not mirror in RTL, and mixed Arabic and numbers that display in the wrong order. Make sure phone and OTP fields open a numeric keyboard. Compress large images and paginate any list longer than 20 items. Report each issue you found and fixed.
Try it in FanannAccessibility: small fixes, real impact
Accessibility is about everyone being able to use your app, including people with low vision, older customers and anyone using a screen reader. It also tends to improve usability for all users. You do not need an audit to cover the basics.
- Text has enough contrast against its background, including on buttons and over photos.
- Every image that carries meaning has a short alt text in the page's language.
- Every form field has a visible label, not just placeholder text that disappears.
- Errors explain what went wrong and how to fix it, next to the field.
- Tap targets are large enough to hit with a thumb.
- The app is usable with system text size increased.
- You can move through forms with a keyboard on desktop, in a logical order.
Backups, staging and rollback
No amount of testing guarantees zero bugs. What separates a small incident from a disaster is whether you can recover quickly. Plan this before launch, not during the problem.
- Backups: confirm your database is backed up automatically, and know how to restore it. A backup you have never restored is a hope, not a plan.
- Staging: try risky changes in a staging copy of the app before they reach customers.
- Rollback: know how to return to the last good version in minutes. A rollback should be a routine action, not an emergency project.
- Version history: keep the code in version control so every change is traceable. Fanann lets you export the full code to GitHub.
- Monitoring: decide who gets alerted when payments fail or errors spike, and how.
The one-page pre-launch checklist
Print this, or paste it into your project notes, and tick each line before you announce your launch.
| Area | Ready when |
|---|---|
| Functional | Every critical flow passes on a phone, for every user role |
| Payments | Success, failure, cancel, refund and duplicate cases all behave correctly in test mode |
| Auth and permissions | Users cannot see or change each other's data, even by editing URLs |
| Security basics | No exposed secrets, validated inputs, rate-limited OTP, private storage |
| Performance | Key pages load quickly on mobile data; images and lists are optimized |
| RTL and mobile | Layouts mirror correctly; no horizontal scroll on small phones |
| Accessibility | Labels, contrast, alt text and readable errors are in place |
| Backups and rollback | A restore has been tested and you know how to roll back |
Then launch small: a soft launch to friends, staff or a waiting list surfaces real-world issues while the stakes are low. If you are working on a tight timeline, our 7-day MVP sprint plan shows where testing fits into the week, and prompting for better apps shows how clearer prompts prevent many bugs before they are written.
Key takeaways
- AI code fails in predictable places: edge cases, permissions, payment states and assumptions about your business rules.
- Automated checks catch build errors and broken flows; only you can confirm the app does what your business actually needs.
- Test payments end to end, including failures, refunds and webhooks, not just the happy path.
- Check that each user can see only their own data, by trying to access someone else's.
- Never launch without a tested backup and a way to roll back to the last good version.
Frequently asked questions
Is AI-generated code less secure than human-written code?
Does Fanann test the code it writes?
Do I need to know how to code to test my app?
How long should pre-launch testing take?
What if I find a bug after launch?
Ask your AI assistant about this
Copy this prompt into the AI assistant you use, then add the details of your own case.
I am reading this guide: “Can you trust AI-generated code? A quality checklist before launch” https://fanann.com/en/blog/testing-ai-generated-code/ My question: how to test an app before launch Use that page as a source and explain the answer step by step for my situation, tell me what to check before I start, and cite the page link.