{"slug": "the-first-qa-checklist-i-would-run-on-any-ai-built-app-in-2026", "title": "The First QA Checklist I Would Run On Any AI-Built App In 2026", "summary": "A developer warns that the most dangerous moment in an AI-built app is when it looks complete but hasn't been properly tested. They propose a simple QA checklist focused on verifying a single user workflow end-to-end, rather than trusting the AI's claim that it works. The checklist includes writing a one-sentence workflow goal, testing the happy path slowly, and refreshing to confirm data persistence.", "body_md": "The most dangerous moment in an AI-built app is not when the app is obviously broken.\n\nThat part is annoying, but at least it is honest.\n\nThe dangerous moment is when the app looks done.\n\nThe buttons are there. The screens load. The AI says it fixed the bug. You click around for thirty seconds and nothing immediately catches fire.\n\nThen your brain starts whispering the sweetest lie in software:\n\n\"We are probably good.\"\n\nProbably good is not a QA strategy.\n\nIt is a tiny trap door with nice lighting.\n\nIf you are a beginner building with AI, you need a first QA pass that is simple enough to actually run. Not an enterprise test plan. Not a 400-line spreadsheet created by someone who uses the phrase \"quality gate\" recreationally.\n\nJust a practical checklist that proves the app can survive normal use, bad input, empty data, account boundaries, and the bugs AI tends to hide while it is \"fixing\" something else.\n\nThe point is not to become a full-time QA engineer before you ship version one.\n\nThe point is to stop treating \"the AI said it works\" as evidence.\n\nWhen I use AI coding tools, I do not trust the app because the code looks busy.\n\nI trust it more when I can walk through a real user workflow and see the app behave correctly from beginning to end.\n\nThat distinction matters.\n\nBeginners often test randomly. They click a few screens, refresh, maybe create one record, and then call the app done because the visible parts seem alive.\n\nBut a useful app is not a pile of screens.\n\nA useful app is a workflow.\n\nSomeone has a goal. They enter information. The app saves it. The app shows it back. The app handles mistakes. The app protects the wrong person from seeing the wrong thing. The app does not collapse when the user does something slightly inconvenient, like leaving a field blank or using the back button.\n\nThat is what you are testing.\n\nIf you are still at the stage where you have an app idea but do not know what to ask AI before building or testing it, I made a free AI App Builder Starter Prompts pack for beginners. It helps you turn a rough app idea into a scoped first build with AI:\n\n[https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts](https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts)\n\nFor QA, the useful question is not:\n\n\"Does the app look done?\"\n\nThe useful question is:\n\n\"Can the user complete the promised workflow without me standing over their shoulder explaining the weird parts?\"\n\nThat is the first pass.\n\nBefore touching the app, write one sentence:\n\n```\nA user should be able to [do one specific job] so they can [get one specific result].\n```\n\nExamples:\n\nThis sentence becomes your QA target.\n\nWithout it, you will test the app like you are wandering through a furniture store.\n\n\"This button works. This page exists. This dropdown opens. This couch is somehow on sale.\"\n\nEverything looks like progress, but you are not proving the thing that matters.\n\nYou are proving that separate parts exist.\n\nQA starts when the parts are forced to work together.\n\nThe happy path is the normal path.\n\nIt is what should happen when the user does everything correctly.\n\nFor a simple app, the happy path might be:\n\nDo not rush this.\n\nAI-built apps can fail in boring places. The save button looks like it worked, but the data never persisted. The edit screen opens, but it is editing the wrong field. The delete button removes the item visually, but it comes back after refresh like a software boomerang.\n\nRun the happy path slowly and write down every expectation before you test it.\n\nGood QA sounds boring:\n\n```\nWhen I create a note called \"Practice riff\" and save it, I should see it in the notes list after refreshing the page.\n```\n\nThat sentence is stronger than \"check notes feature.\"\n\n\"Check notes feature\" is a fog machine.\n\nSpecific expected behavior is a flashlight.\n\nOne beginner mistake is trusting the screen state too much.\n\nModern apps can make something look saved before it is actually saved where it needs to live.\n\nSo refresh.\n\nRefresh after creating data.\n\nRefresh after editing data.\n\nLog out and log back in.\n\nClose the tab and reopen it.\n\nIf it is a mobile app, kill and reopen the app.\n\nYou are checking whether the app has real persistence or just temporary optimism.\n\nThis matters especially with AI-generated code because the tool may wire up a beautiful interface before the data flow is truly correct.\n\nThe screen can be convincing while the backend is silently shrugging.\n\nI want to know:\n\nIf the answer is unclear, the app is not done.\n\nIt is wearing a done costume.\n\nUsers do not lovingly fill out every field like they are completing a sacred ritual.\n\nThey skip things.\n\nThey paste weird text.\n\nThey submit forms early.\n\nThey type one letter and then get distracted by a microwave beep or the sudden realization that they forgot to respond to an email from four days ago.\n\nYour app needs to handle this.\n\nFor every important form, test:\n\nYou are not trying to be dramatic.\n\nYou are trying to find the places where the app assumes the user behaves like the developer.\n\nThat assumption is usually false.\n\nAI-generated code can be especially optimistic here. It may build the form, connect the button, and skip the boring validation rules unless you explicitly ask for them.\n\nAsk for them.\n\nThen test them yourself.\n\nAn empty state is what the app shows when there is no data yet.\n\nBeginners forget this constantly because they build while staring at fake sample data.\n\nThe app looks great when it has five beautiful placeholder records.\n\nThen a real new user signs in and sees a blank void with a navigation bar.\n\nThat is not a first impression.\n\nThat is a small abandoned warehouse.\n\nFor each main screen, ask:\n\nA good empty state does not need to be clever.\n\nIt just needs to answer:\n\n\"What now?\"\n\nIf your app cannot answer that, the user has to guess.\n\nGuessing is friction.\n\nFriction is where beginner apps quietly lose people.\n\nIf your app has accounts, this part is not optional.\n\nYou need at least two test accounts.\n\nNot one.\n\nTwo.\n\nAccount A should not see Account B's private data.\n\nAccount B should not edit Account A's records.\n\nLogged-out users should not reach private screens just by typing a URL.\n\nThis is where \"it works on my machine\" becomes dangerous, because your machine is probably logged in as the same test user all the time.\n\nCreate two accounts and test:\n\nDo not rely on vibes here.\n\nAuthentication is the bouncer at the door.\n\nIf the bouncer is asleep, the furniture arrangement does not matter.\n\nWhen something breaks, the beginner instinct is to paste the error into AI and say:\n\n\"Fix this.\"\n\nThat can work.\n\nIt can also create a chain of tiny surgical fixes that solve the visible symptom while quietly damaging the larger workflow.\n\nI prefer to slow the tool down.\n\nBefore asking for a fix, ask for a test plan.\n\nUse a prompt like this:\n\n```\nI am testing this workflow:\n[describe the workflow]\n\nThe bug I saw is:\n[describe the bug]\n\nBefore changing code, explain:\n1. the likely causes\n2. which files or areas might be involved\n3. what behavior should be true after the fix\n4. what regression checks I should run\n5. the smallest safe fix you recommend\n\nDo not write code yet. Give me the plan first.\n```\n\nThis is one of the reasons I include QA and debugging prompts in the free AI App Builder Starter Prompts pack. The useful move is not asking AI to magically fix everything. The useful move is forcing it to name the expected behavior before it changes the project:\n\n[https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts](https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts)\n\nThat step protects you from the AI tool becoming a very confident racetrack for random patches.\n\nPlanning before fixing sounds slower.\n\nIn practice, it often saves time because you stop turning one bug into three new bugs wearing different hats.\n\nThis is the regression pass.\n\nRegression is when a new change breaks something that used to work.\n\nAI can do this very easily because it is often focused on the local task you just gave it.\n\nIt fixes the signup bug, but now profile editing breaks.\n\nIt fixes the save button, but now the list does not refresh.\n\nIt fixes the mobile layout, but now the desktop layout looks like someone folded the page in half and sat on it.\n\nAfter every meaningful fix, re-test:\n\nThis is not glamorous.\n\nIt is also where a lot of real software quality lives.\n\nThe question is not:\n\n\"Did AI fix the bug?\"\n\nThe question is:\n\n\"Did the app still keep its promises after the fix?\"\n\nYou do not need to simulate every disaster for version one.\n\nBut you should at least check what happens when loading is slow or data is missing.\n\nBeginner apps often fail because they assume everything appears instantly.\n\nThen the real world arrives with a weak connection, a slow request, a failed upload, or a backend rule that rejects something.\n\nCheck:\n\nEven one pass here can reveal a lot.\n\nIf your app shows nothing while loading, users may click again.\n\nIf your app shows a technical error, users may leave.\n\nIf your app silently fails, users may think they did something wrong.\n\nSilence is not a user experience.\n\nIt is a mystery novel with no ending.\n\nBefore you call the app done, write a done-when line.\n\n```\nThis workflow is done when a new user can create an account, create one project, edit it, see it after refresh, delete it, and confirm another account cannot access it.\n```\n\nThat is much stronger than:\n\n```\nProject screen finished.\n```\n\nFinished according to whom?\n\nFinished under what conditions?\n\nFinished until which user clicks which cursed button?\n\nA done-when line gives you a finish line you can test.\n\nIt also gives AI a better target. If you tell the tool exactly what done means, it has less room to wander into cosmetic improvements, extra features, or random refactors that do not help the first version.\n\nThis is one of the main lessons I keep learning in freelance work and AI-assisted development:\n\nClear definitions beat heroic effort.\n\nThe app does not care how hard you worked.\n\nThe user does not care how many files changed.\n\nThe workflow either works or it does not.\n\nIf I had to turn this into a simple checklist, I would run this:\n\n```\n1. Write the one user workflow.\n2. Run the happy path slowly.\n3. Refresh after create, edit, and delete.\n4. Test empty and invalid inputs.\n5. Check brand-new empty states.\n6. Use two accounts and test boundaries.\n7. Ask AI for a test plan before bug fixes.\n8. Re-test old behavior after every fix.\n9. Check one loading or error state.\n10. Write the done-when line in plain English.\n```\n\nThat is not a complete QA department.\n\nIt is a first pass.\n\nBut a first pass is much better than the usual beginner pattern:\n\nClick around, feel hopeful, ship, panic.\n\nAI can help you build faster.\n\nIt can also help you create a mess faster.\n\nQA is how you slow the project down just enough to keep control.\n\nThe practical takeaway:\n\nDo not ask, \"Does the app look done?\"\n\nAsk, \"Can the user complete the promised workflow, recover from mistakes, and trust the data afterward?\"\n\nThat question will make your AI-built app better immediately.\n\nI made a free AI App Builder Starter Prompts pack for beginners who want to turn a rough app idea into a scoped first build with AI:\n\n[https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts](https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts)\n\nIf you want the full build-along field manual behind the free prompts, AI App Builder From Zero walks through idea, scope, stack, prompting, QA, deployment, and launch:\n\n[https://marcusykim.gumroad.com/l/ai-app-builder-from-zero](https://marcusykim.gumroad.com/l/ai-app-builder-from-zero)\n\nMedium: [https://medium.com/@contact_30652](https://medium.com/@contact_30652)\n\nDEV.to: [https://dev.to/marcusykim](https://dev.to/marcusykim)\n\nX: [https://x.com/contact_30652](https://x.com/contact_30652)\n\nLinkedIn: [https://www.linkedin.com/in/marcusykim/](https://www.linkedin.com/in/marcusykim/)", "url": "https://wpnews.pro/news/the-first-qa-checklist-i-would-run-on-any-ai-built-app-in-2026", "canonical_source": "https://dev.to/marcusykim/the-first-qa-checklist-i-would-run-on-any-ai-built-app-in-2026-3p3g", "published_at": "2026-06-20 17:30:00+00:00", "updated_at": "2026-06-20 18:06:55.016667+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "ai-products"], "entities": ["Marcus Y. Kim"], "alternates": {"html": "https://wpnews.pro/news/the-first-qa-checklist-i-would-run-on-any-ai-built-app-in-2026", "markdown": "https://wpnews.pro/news/the-first-qa-checklist-i-would-run-on-any-ai-built-app-in-2026.md", "text": "https://wpnews.pro/news/the-first-qa-checklist-i-would-run-on-any-ai-built-app-in-2026.txt", "jsonld": "https://wpnews.pro/news/the-first-qa-checklist-i-would-run-on-any-ai-built-app-in-2026.jsonld"}}