100 AI App Builder Prompts for Non-Developers

Ask me 7 questions, one at a time, about my work, routines, customers, and frustrations. Then suggest 5 small app problems I understand well. Do not suggest features until you explain the problem.

Here is the problem: [PROBLEM]. Give me 3 app approaches. For each, name the user, the painful moment, the smallest useful action, and what the app should not try to do.

Review this app idea: [IDEA]. Score problem clarity, frequency, urgency, build difficulty, and testability from 1 to 10. Give evidence for each score and tell me what to simplify.

For this idea [IDEA], help me choose one specific first user. Compare these audiences: [AUDIENCES]. Recommend one and explain what would make the choice wrong.

Reduce [IDEA] to a version-one scope. Output one user, one problem, one core workflow, no more than 3 screens, required data, and a list of features to postpone.

Write a one-page product brief for [IDEA] in plain English. Include user, problem, promise, core workflow, non-goals, risks, and a simple definition of done.

Design a manual test for [IDEA] that I can run with 3 real people before building. Include the script, questions, success signals, and what would make me change the idea.

Suggest 15 clear names for [IDEA]. Avoid invented hype, guaranteed outcomes, and names that imply features the app will not have. Explain the strongest 3.

Map the first-time journey for [USER] using [APP IDEA]. Show trigger, first action, key decision, successful outcome, and where the user may get confused.

Given this idea, budget, time, and skill level [DETAILS], compare a web app, Android app, and iOS app. Recommend the smallest sensible first platform and explain the tradeoffs.

Before changing any files, inspect this project and report: what it does, the entry points, the likely files for [TASK], risks, and a proposed plan. Do not edit anything.

Audit the bug [BUG]. Trace the user action from screen to data or API. List evidence, likely causes, files involved, and tests that would confirm the cause. Do not fix yet.

Review this feature request: [REQUEST]. Explain what already exists, what is missing, what could break, and the smallest implementation plan. Do not change files.

Inspect package and dependency files. Identify outdated, duplicated, unused, or risky dependencies relevant to [TASK]. Do not upgrade anything; report possible impact first.

List every environment variable this project references, where it is used, whether it belongs on the server or client, and what would break if it were missing. Never print secret values.

Trace how [DATA] enters, changes, and leaves this app. Include UI, validation, API, database, and error states. Flag any place where data could be lost or exposed. Do not edit.

Inspect the relevant screens at 375px, 768px, and desktop widths. Report overflow, tiny tap targets, clipped text, keyboard issues, and the smallest safe fixes. Do not edit.

Review [PAGE/FEATURE] for keyboard access, focus visibility, labels, heading order, contrast, error messaging, and reduced motion. Give findings with file references. Do not edit.

Before refactoring [AREA], identify public behavior that must remain unchanged, current tests, hidden dependencies, and a reversible sequence of small changes. Do not refactor.

Create a concise audit report for [TASK] with sections: current behavior, evidence, risks, recommended next step, files involved, tests needed, and questions for me. Do not claim anything you did not verify.

Fix only this bug: [BUG]. First inspect the relevant code. Change the smallest number of files. Do not refactor, rename, or reformat unrelated code. Run the narrowest useful test and report the diff.

Explain this error in plain English: [ERROR]. Identify the exact failing step, likely cause, safe next check, and what information is still missing. Do not invent a fix.

Fix [BUG] while preserving all existing behavior except [EXPECTED CHANGE]. List the behavior you will protect, then implement and test the smallest fix.

Find where [SCREEN] handles empty, loading, success, and error states. Add or correct the missing state for [CASE]. Keep the current visual style and do not change the data model.

Audit and fix this form issue: [ISSUE]. Preserve field names and backend contracts. Add clear validation and error messages only where needed. Test blank, invalid, valid, and repeated submissions.

Find why [LINK/ACTION] does not reach [DESTINATION]. Trace the route and click handler, make the smallest fix, and verify the destination and back-navigation.

Investigate why the UI shows [VALUE] while the database/API has [VALUE]. Compare types, field names, transforms, and caching. Report evidence before editing, then make one targeted fix.

Fix [BUG] without swallowing exceptions or replacing a real error with a success message. Preserve useful logs and give the user a clear recovery action.

After fixing [BUG], add the smallest regression test that would fail before the fix and pass after it. Explain what the test proves and what it does not prove.

If you cannot verify the cause of [BUG] from the available files, stop. Give me the evidence, the missing information, and the safest manual check instead of guessing.

Review [PAGE] as a first-time user. Identify the primary action, secondary actions, confusing copy, weak hierarchy, and unnecessary elements. Suggest a small improvement plan before editing.

Improve only [SCREEN] for clarity and trust. Keep the current design system, routes, and behavior. Prioritize spacing, hierarchy, readable copy, and useful states. Report every changed file.

Make [SCREEN] work at 375px wide. Prevent horizontal scrolling, preserve readable text, keep tap targets comfortable, and test the main flow. Do not redesign desktop.

Review empty states in [AREA]. For each, explain what happened, why it matters, and the next useful action. Implement only the missing copy or action.

Rewrite error messages in [AREA] so a non-developer knows what happened, what they can do next, and when to contact support. Keep technical details out of the user-facing message.

Audit [FLOW] for loading feedback. Add only honest loading, disabled, and retry states. Do not use fake progress or claim work completed before it is confirmed.

Review [PAGE] for text contrast, focus indicators, keyboard navigation, and visible button states. Fix only verified issues and list any issues that need manual browser testing.

Find decorative or repeated UI on [PAGE] that competes with the main action. Recommend what to remove or reduce while preserving useful context. Do not add gradients or animations.

Rewrite the headings and buttons on [PAGE] to say what the user will get or do. Keep claims factual and avoid hype, fake urgency, and vague phrases like “level up”.

Compare the current [SCREEN] with this goal [GOAL]. Tell me whether the change improves comprehension, task completion, mobile usability, and trust. Recommend no change if it does not.

Search the relevant UI for user-visible strings that should come from content, configuration, or translation. Return file, line, text, and why it is risky. Do not edit.

Find hardcoded URLs, hostnames, callback URLs, and API paths. Separate safe public routes from environment-specific values and secrets. Never expose secret values.

Check [AREA] for names, emails, IDs, prices, plans, or account values hardcoded into UI or logic. Report each occurrence and the correct source of truth.

Audit [FEATURE] for role names, user IDs, or access checks hardcoded in the client. Explain what must be enforced server-side and do not claim client checks are security.

Search [AREA] for dates, time zones, currency symbols, and number formats that are hardcoded. Report locale risks and propose the smallest consistent formatting fix.

Find lorem ipsum, TODO text, “coming soon”, fake counts, sample emails, and placeholder buttons visible to users. Separate intentional planned copy from content that must be removed before launch.

Find repeated labels and messages in [AREA] that could drift. Report duplicates and suggest a shared constant or content source only where it improves maintainability.

Separate hardcoded test/demo data from production data in [AREA]. Confirm that demo accounts, sample payments, and fixtures cannot appear in a real user flow.

Replace only this user-visible string [TEXT] with the project’s existing content pattern. Do not introduce a new localization system or change unrelated copy.

Search [AREA] for unverified testimonials, subscriber counts, ratings, revenue, or “used by” claims. Report them and recommend factual alternatives. Do not invent replacements.

Audit this app’s Supabase usage without printing secrets. Inspect schema references, client/server boundaries, RLS migrations or policies, storage, auth, and service-role usage. Report evidence and unknowns; do not change anything.

Explain what Row Level Security should protect for the [TABLE] table. Based on the app’s user ownership rules, list expected policies and tests. Do not create policies without confirming the data model.

Find Supabase keys and calls in client code. Confirm the anon key is treated as public, the service-role key is server-only, and no secret or privileged operation is shipped to the browser.

For [TABLE], trace how the current user is identified and how ownership is enforced in database policies. Flag any trust placed only in client-supplied user IDs.

Audit Supabase Storage buckets used by [FEATURE]. Report public/private status, upload restrictions, object ownership, download paths, and deletion behavior. Do not change bucket policies.

Review signup, login, logout, reset, email verification, and session refresh for [APP]. List failure states and data-access risks. Do not weaken auth to make a test pass.

List the fields returned to the client from [TABLE/QUERY]. Identify unnecessary personal, payment-related, or internal fields and recommend the smallest safer response.

Inspect database migrations for [FEATURE]. Report missing constraints, unsafe defaults, destructive operations, and whether the migration can be rolled back or tested safely.

Create a test plan for [TABLE/FEATURE] covering anonymous, owner, non-owner, and admin-like users. State expected allow/deny results. Do not claim security is proven without running tests.

If RLS, auth, storage, or secret handling cannot be verified from this repository, stop and report exactly what must be checked in the Supabase dashboard or logs.

Trace [PAYMENT FLOW] from checkout click to provider event, database record, entitlement, and cancellation. Report evidence, retry behavior, and missing states. Do not edit.

Audit [PAYMENT FEATURE] for prices, plan IDs, access flags, or payment status trusted from the browser. Identify where server/provider verification is required.

Review webhook handling for [EVENTS]. Check signature verification, duplicate events, retries, idempotency, logging, and user-facing status. Do not weaken verification.

Find whether payment test mode, test keys, test products, and demo bypasses can reach production. Report how they are separated and what needs manual verification.

Review when a user gains and loses access after payment, cancellation, refund, failure, or webhook delay. Identify confusing or unsafe states.

Compare displayed prices, currency, tax wording, billing interval, and provider checkout values for [PLAN]. Report mismatches without guessing the correct price.

Audit [CHECKOUT] for repeated clicks, refreshes, retries, and network failures. Explain what prevents duplicate purchases and what needs a provider-side check.

Review payment and refund copy for [PRODUCT]. Make it clear what is charged, when access changes, and where the user can request help. Avoid legal guarantees.

Write a manual test matrix for success, decline, cancellation, timeout, duplicate webhook, refund, and expired access. Include expected UI and database state.

Give me a report of what this code can prove about payment correctness and what requires provider dashboard, test-mode, or production monitoring checks. Do not say “secure” without evidence.

Review [APP] for release blockers across app identity, permissions, privacy, network failures, offline behavior, screenshots, and signed builds. Separate verified issues from unknowns.

Create an Android release checklist for this project covering application ID, versioning, signing, target SDK, permissions, deep links, privacy policy URL, and Play Console testing.

Create an iOS release checklist for this project covering bundle ID, signing, capabilities, versioning, privacy manifest, permissions, screenshots, TestFlight, and App Store metadata.

List every Android/iOS permission the app requests, where it is used, why it is needed, and what happens if the user denies it. Remove no permission without checking the feature.

Write a first-launch test for a fresh install of [APP], including permission denial, no account, slow network, interrupted setup, and returning user behavior.

Draft factual store title, short description, long description, and screenshot captions for [APP]. Do not promise outcomes or features that are not implemented.

Map the app’s collected data, purpose, sharing, retention, and deletion behavior so I can answer store privacy questions accurately. Flag anything the code cannot confirm.

Audit how crashes and errors are handled in the release build. Report whether logs include personal data and what manual test confirms the app fails gracefully.

Create a small closed-test plan for [APP] with tester tasks, devices, network conditions, feedback questions, and release-blocking bug rules.

Give me a final store-submission report with verified ready items, blockers, manual checks, and questions for legal/privacy review. Do not claim approval is likely.

Run a read-only GitHub status check. Tell me the current branch, changed files, untracked files, recent commits, and whether the working tree is clean. Do not commit, reset, checkout, or delete.

Before [CHANGE], tell me how to create a clear Git checkpoint and what should be reviewed. Do not run Git commands that change history until I confirm.

Review the current diff for [TASK]. Summarize intended changes, unrelated changes, secrets, risky files, and missing tests. Do not edit or commit.

Explain this branch situation in plain English: [PASTE STATUS]. Tell me which branch contains what and the safest next action. Do not merge or delete anything.

If the current diff contains only [TASK], propose a commit message and list the exact files that should be included. Stop if unrelated or secret files are present.

Explain these merge conflicts in plain English: [CONFLICT]. Identify the choices and behavior at risk. Do not resolve conflicts until I approve the intended behavior.

I think [CHANGE] broke the app. Inspect status, diff, and recent commits read-only. List recovery options from least destructive to most destructive. Do not reset or discard work.

Audit tracked and untracked files for likely secrets, keys, tokens, and environment files without printing values. Report safe remediation steps and whether history may contain exposure.

Compare the current branch with [MAIN BRANCH] read-only. Summarize commits, files, behavior changes, and likely merge risks. Do not merge.

Write a GitHub handoff report for the next AI session: current branch, last known good commit, changed files, tests run, remaining risk, and exact next step. Use verified facts only.

Inspect the production build configuration for [APP]. Report build command, output, environment variables, redirects, headers, migrations, and anything that differs from local development. Do not deploy.

List development, preview, and production environment values by name only. Identify values that must differ and confirm no secret is hardcoded or logged.

Review this project for Netlify deployment assumptions: build command, publish directory, functions, redirects, forms, headers, and runtime version. Report what must be verified in Netlify.

Create a manual verification checklist for domain, DNS, HTTPS, www/non-www redirect, canonical URL, robots, sitemap, and social previews. Do not claim DNS is correct without checking the provider.

Review pending database changes for [FEATURE]. Explain order, backups, compatibility, rollback options, and a safe test environment. Do not run migrations.

List production failures that could be invisible to a user or owner in [APP]. Recommend honest logging and alerts without logging secrets or unnecessary personal data.

Audit [PAGE/DATA] for stale cache, missing invalidation, or private data accidentally cached publicly. Report evidence and manual tests.

Review redirect rules for loops, missing trailing-slash behavior, old resource URLs, and accidental redirects of authenticated pages. Do not change unrelated routes.

Write a rollback plan for [RELEASE] covering code, database, environment variables, and user communication. Identify the point where rollback becomes unsafe.

Produce a pre-deployment report with verified checks, blockers, manual checks, and exact owner for each unknown. Do not deploy or say ready when a blocker is unresolved.

Write a complete manual test for a new user completing the main workflow in [APP]. Include expected result after every step and the data that should be saved.

List the 12 most important failure cases for [APP] and the expected user-facing recovery for each. Prioritize data loss, money, auth, and privacy.

Create a support handoff for [APP]: common problems, what information to request, safe troubleshooting steps, and what requires escalation. Do not request passwords or secrets.

Review [APP] for privacy policy link, data collection explanation, account deletion path, contact method, and third-party services. List what the code verifies and what needs owner confirmation.

Test every public form for labels, validation, duplicate submits, success/error states, delivery, spam handling, and privacy wording. Do not create a fake submission or claim delivery without evidence.

Document what is backed up for [APP], how often, who can restore it, and how a restore would be tested. Flag assumptions about GitHub, Supabase, Netlify, or payment providers.

List the events [APP] actually sends and whether they contain personal data. Identify missing events for the main funnel. Do not add fake numbers or call an event proof of success.

Proofread [APP] for unclear labels, typos, empty placeholders, contradictory promises, and unverified claims. Suggest factual copy and leave legal claims for review.

Using this checklist and evidence [PASTE REPORT], classify each item ready, blocked, unknown, or not applicable. Recommend launch only if critical data, payment, auth, recovery, and user-flow checks are verified.

Create a dated launch record with version, last known good commit, deployment URL, migrations, tests, known issues, rollback plan, and owner. Include unknowns instead of filling gaps.