Scope
Choose one useful idea and decide what belongs in the smallest first version.
Free AI app prompt pack
Move from a loose idea to a small, tested, mobile-ready app by asking AI for the right help at each step.
Start with prompt oneRead the first two prompts now. Unlock the remaining eight free.
Beginner-friendly prompt pack
A simple working loop
Each prompt has one job. Use them in order for a new project, or jump to the step that matches the problem in front of you.
Choose one useful idea and decide what belongs in the smallest first version.
Create the first screen, understand the output, and test the behavior.
Debug the cause, protect what works, improve mobile use, and prepare to share.
How to use every prompt
Use it in the AI building or coding tool you already have.
Make the user, outcome, constraints, and current problem specific.
Share relevant files, errors, screenshots, or behavior without exposing secrets.
Confirm the result yourself before moving to the next prompt.
Start reading
Copy them as written, then replace the bracketed details with your own idea.
When to use: When you have several ideas, or only a broad problem, and need one realistic place to start.
I want to build a small app with AI, but I need help choosing one useful idea.
Here are three problems or tasks I understand:
1. [problem or task one]
2. [problem or task two]
3. [problem or task three]
Compare them using these criteria:
- I understand the user and the problem.
- The first version can produce one visible result.
- It can work without accounts, payments, or advanced integrations.
- I can test it with realistic examples.
Recommend one idea for my first app. Explain why it is the best starting point, what the user will accomplish, and what evidence would show that it works.When to use: After choosing the idea, before asking AI to build screens or write code.
Help me define the smallest useful first version of this app:
App idea: [one-sentence idea]
Primary user: [who will use it]
Visible outcome: [what the user should accomplish]
Create a V1 scope with:
1. One primary user journey.
2. No more than three actions the user can take.
3. The minimum information the app needs.
4. A clear success condition I can test.
5. A short list called "Not in V1."
Prefer one screen and local sample data unless the outcome truly requires more. Ask me up to three questions only if the answers would materially change the scope.You can now read and copy all 10 prompts.
When to use: When the requested build is growing faster than your understanding of it.
Review this proposed first version:
[paste the current scope or feature list]
Separate it into:
- Essential now: required for the one visible outcome.
- Useful later: valuable, but not required to test the idea.
- Avoid for this version: complexity that introduces accounts, permissions, payments, integrations, or infrastructure before they are necessary.
Return a reduced V1 with one primary journey and explain the risk removed by each exclusion. Do not add replacement features.When to use: When the scope is stable enough to create a working interface.
Build the first working screen for this app:
User: [primary user]
Outcome: [one visible outcome]
Essential actions: [two or three actions]
Information shown: [minimum fields or results]
Not in V1: [excluded features]
Make it mobile-first, accessible, and easy to understand without instructions. Use realistic sample data. Include an empty state, a clear primary action, and simple validation. Preserve the existing project structure and working behavior. Before changing files, summarize your plan in five bullets or fewer.When to use: After a build works, but you do not yet understand the important pieces.
Explain the current app to a complete beginner.
Cover only what I need to make the next safe change:
1. Which files control the visible screen.
2. Where the app stores or receives its data.
3. What happens after the primary action.
4. Which validation or error states exist.
5. What is temporary, mocked, or not production-ready.
For each point, cite the relevant file or component. Use plain language, define unavoidable technical terms, and finish with three questions I should be able to answer before continuing.When to use: Before accepting a feature as complete.
Create a practical test checklist for this behavior:
[describe the feature or change]
Include:
- The normal successful path.
- Required information left empty.
- Very short and very long text.
- Duplicate or repeated actions.
- Refreshing or reopening the app.
- A small phone screen and a wider desktop screen.
- Keyboard navigation and visible focus.
- One realistic failure outside the user’s control.
For every test, state the action, expected result, and visible evidence. Separate tests I can perform manually from tests that should be automated.When to use: When something fails and random edits would create more uncertainty.
Help me diagnose this problem before changing code.
Expected behavior: [what should happen]
Actual behavior: [what happens instead]
Steps to reproduce: [exact steps]
Error message or screenshot details: [paste them]
Last known working state: [what worked before]
Recent change: [what changed]
Identify the three most likely causes in order. For each cause, give me one observation or safe check that would confirm or reject it. Do not propose a fix until the evidence identifies the failing layer. Then recommend the smallest fix and the tests needed to prove it.When to use: Before changing a part of the app that already works.
I need to make this change:
[describe the requested change]
These behaviors already work and must remain unchanged:
[list the working behaviors]
Before editing:
1. Identify the files and behaviors at risk.
2. Add or confirm tests for the working behavior.
3. Propose the smallest scoped change.
After editing, run the relevant existing tests and the new regression tests. Report exactly what changed, what was deliberately untouched, and any assumption you could not verify. Do not rewrite unrelated components.When to use: After the core workflow works on desktop and needs a deliberate phone review.
Review this working app for phone use without redesigning its identity.
Primary user journey: [describe the journey]
Target phone width: [for example, 390px]
Screenshots or files: [provide them]
Check:
- No horizontal overflow or clipped content.
- Readable text without zooming.
- Touch targets at least 44px high or wide.
- The primary action remains easy to reach.
- Forms use appropriate input types and labels.
- Keyboard opening does not hide the active field or action.
- Long content wraps without breaking the layout.
- Focus, error, loading, and empty states remain visible.
Rank the issues by impact, then implement only the high-impact fixes. Preserve working desktop behavior and verify both widths afterward.When to use: When the app works locally and you are preparing to let another person use it.
Review this app for a small real-world launch.
App purpose: [one sentence]
Intended users: [who will receive it]
Deployment target: [where it will run]
Data handled: [what information it stores or sends]
Check and classify each item as Ready, Needs work, or Not applicable:
- Production build and automated tests.
- Environment variables and secret handling.
- Data persistence, backup, and deletion.
- Authentication and permissions, if needed.
- Validation, error handling, and recovery.
- Basic security and dependency risks.
- Mobile and accessibility checks.
- Logging or a way to understand failures.
- Clear setup, usage, and maintenance notes.
Do not claim production readiness from code inspection alone. Give me a prioritized launch checklist, the evidence required for each item, and the smallest safe sharing option if permanent launch is premature.Inside the pack
Frequently asked questions
No. The prompts tell the AI what context to request and ask it to explain important decisions. You still need to test the result and avoid sharing secrets or private data.
Use the AI building or coding tool you already have access to. The prompts focus on scoping, evidence, and safe iteration rather than one platform’s commands.
Yes. You can copy and adapt the prompts on a phone. Whether the full build can be completed there depends on the tool and the computer or hosted workspace connected to it.
Yes. Replace the bracketed fields and current context each time. The structure is designed to work across different small app ideas.