Copy-paste prompts for every stage of building with AI — from idea to launch to your first paying user. Tested phrasing, fill-in placeholders, works with any model.
You have a rough idea and want a clear, buildable spec before you start prompting for code.
You are a senior product engineer. I want to build: [describe your idea in 1-3 sentences]. Before writing any code, produce a short build spec: 1. One-sentence summary of what it does and who it's for. 2. The single core user flow, step by step. 3. The 3-5 screens or pages needed (no more). 4. The data I need to store (list the fields). 5. A recommended stack, with one boring, well-supported choice per layer. 6. What to deliberately leave OUT of v1. Keep it tight. Favor the smallest thing that delivers the core value. Ask me up to 3 clarifying questions only if you genuinely can't proceed without them.
Your idea is too big. Use this to cut it down to something you can finish before the motivation fades.
Here is my project idea and the features I'm imagining: [paste your idea and feature list] Act as a ruthless but kind technical co-founder. Cut this down to what one person can build and ship in a single weekend. - List the must-haves for the core value to work at all. - Move everything else to a "later" list with one line on why it can wait. - Flag any feature that's secretly a multi-week project hiding in a one-line bullet. - End with the exact order I should build the must-haves in.
You're not sure what framework, database, or hosting to use and don't want to repaint yourself into a corner.
I'm building: [one-sentence description]. My experience level: [beginner / comfortable / experienced]. It needs to: [list 2-4 hard requirements, e.g. user accounts, file uploads, payments]. Recommend a stack optimized for shipping fast and not getting stuck: - Frontend framework, backend, database, auth, hosting. - For each, pick the most boring, well-documented option that meets my requirements, and say why in one line. - Call out anything in my requirements that will be unexpectedly hard, and the simplest way to handle it. - Avoid trendy tools unless they clearly save me time here.
Before building features, you want the data right — the shape everything else depends on and the hardest thing to change later.
I'm building: [one-sentence description]. The main things users create or interact with are: [list the nouns, e.g. projects, tasks, comments]. Design the data model before any code: - List the core entities (tables) and the fields each needs, with types. - Show how they relate (one-to-many, many-to-many) and where the foreign keys live. - Flag any field that should be required, unique, or indexed, and why. - Point out the one or two modeling decisions that will be painful to change later, and recommend a default. Keep it minimal — only what v1 actually needs. Don't add tables for features I haven't asked for.
Something threw an error and you want the cause and a fix, not just a patch over the symptom.
I'm getting this error: [paste the full error message and stack trace] Here's the relevant code: [paste the file or function the trace points to] Do this in order: 1. Explain in plain language what this error actually means. 2. Name the most likely root cause, and how you can tell from the trace. 3. Give me the minimal fix, with the exact lines to change. 4. Tell me one thing I can check to confirm it's really fixed and not just hidden. Don't rewrite unrelated code.
A value is empty, undefined, or null when you expected data, and you can't see why.
This value is [undefined / null / empty] when I expect it to have data: [name the variable]. Here's where it's set and where it's used: [paste both the source and the usage] Trace the data flow from where this value originates to where it breaks. At each step, tell me what the value should be and where it could become empty. Then give me the one most likely point of failure and the fix. If you need to see another file to be sure, tell me exactly which one and why.
Something that used to work is now broken and you don't know which change did it.
This feature worked before and is now broken: [describe the broken behavior vs. expected]. Here are my recent changes (git diff or description): [paste git diff or describe what you changed recently] Assume the bug is in one of these changes. Walk through them and rank which is most likely to have caused this, with reasoning. Give me the fix for the top suspect, and tell me how to quickly rule it in or out before I change anything.
A bug is intermittent or vague and you keep guessing at fixes. Nail down a reliable repro first.
I have a bug I can't fix reliably because I can't reliably trigger it: [describe the wrong behavior and when it seems to happen]. Here's the relevant code: [paste it]. Help me reproduce it on purpose before we fix anything: 1. List the conditions that could trigger this (inputs, state, timing, environment). 2. Give me the smallest, most reliable set of steps to make it happen every time. 3. Tell me what to log or inspect to confirm I've actually reproduced the real bug, not a lookalike. Only once we have a solid repro, propose the fix. Don't patch blindly before then.
One file or component is doing too much and is getting hard to change safely.
This file has grown too large and does too many things: [paste the file] Refactor it WITHOUT changing behavior: - Identify the distinct responsibilities mixed together. - Propose a clean split into smaller files/functions, with names that say what they do. - Show me the new file structure first, then the code. - Keep the public interface the same so nothing else breaks. - Note anything that looks like a bug you found along the way, but don't fix it in this pass — just flag it.
Code works but is hard to follow — vague names, unclear flow, too clever.
This code works but is hard to read: [paste the code] Rewrite it to be obvious to a tired developer at 3am, without changing what it does: - Rename variables and functions to say what they hold or do. - Replace clever one-liners with explicit, readable steps where it helps. - Add a short comment only where the "why" isn't obvious from the code. - Don't add abstractions I don't need yet. Keep the diff focused on clarity.
You've copy-pasted similar logic in a few places and want to consolidate it safely.
I think I have duplicated logic across these files: [paste the files or functions] Find the real duplication (same logic, not just similar-looking code). For each cluster: - Show me what's actually repeated. - Propose one shared function or module, with a clear name and where it should live. - Show the before/after for one call site so I can see the change. Only consolidate things that are truly the same. If two things look alike but will likely change for different reasons, leave them separate and say so.
You want to refactor code that has no tests, and you're worried about silently breaking behavior.
I want to refactor this code, but it has no tests and I'm afraid of changing what it does: [paste the code] Before any refactor, help me pin down current behavior: - Identify the key behaviors and edge cases this code has today, including the weird ones that might be load-bearing. - Write a small set of characterization tests that capture how it behaves right now (not how it "should" behave). - Point out any behavior that looks like a bug, but write the test to match current reality and flag it separately. Once these tests pass against the existing code, I'll refactor with them as a safety net. Don't change the code yet.
You think it's ready to share publicly and want to catch the obvious gaps first.
I'm about to launch this app: [describe what it does and the main user flow]. Give me a pre-launch checklist tailored to it, grouped into: must-fix before launch, should-fix soon, and nice-to-have. Cover at least: - The core flow working end to end for a brand-new user. - Broken/empty/error states (no data, bad input, network failure). - Mobile layout. - Obvious security gaps (exposed keys, open endpoints). - Basic SEO and social preview (title, description, share image). Be specific to my app, not generic. Put the one thing most likely to embarrass me on launch day at the top.
The code is done but the README is empty and your page has no title or share preview.
Here's my project — code structure and what it does: [paste your file tree and a short description, or your package.json] Produce two things: 1. A clean README: one-line description, what it does, how to run it locally, and how to deploy. Short and skimmable. 2. The HTML/meta tags for a good title, description, and social share preview (Open Graph + Twitter), using this product name and tagline: [name + tagline]. Write for a real person landing cold, not for me. No filler.
Your happy path works but you never handled failures, empty states, or bad input.
Here's a feature that only handles the happy path: [paste the code] Make it robust for real users without over-engineering: - List every way this can fail (bad input, network error, empty result, slow response). - For each, add handling that gives the user a clear message and a way to recover. - Make sure nothing fails silently. - Show me the updated code, and keep the changes focused on failure handling.
Before you push to production, you want a focused check for the security mistakes AI-built apps make most.
I'm about to deploy this app: [describe what it does, its auth, and what data it stores]. Here are the key files — API routes, auth, and anything touching the database or secrets: [paste the relevant files] Do a focused security pass, in priority order: 1. Secrets: any hardcoded API keys, tokens, or credentials that should be environment variables? Anything secret that could reach the client bundle? 2. Auth: does every protected route and data query actually check who the user is AND that they're allowed to access that specific data (not just logged in)? 3. Input: anywhere untrusted input reaches a database query, shell, file path, or outbound request without validation? 4. Exposure: any debug routes, admin endpoints, or verbose error messages that leak internals? For each finding: where it is, why it matters, and the minimal fix. Rank by real-world risk. Don't rewrite unrelated code.
The page works but feels cluttered or amateur — uneven spacing, no clear focal point.
Here's the markup/styles for a page that feels a bit off: [paste the component or HTML/CSS] Act as a product designer. Improve the visual hierarchy and spacing without redesigning it: - Establish a consistent spacing scale and apply it. - Make the most important element clearly the focal point. - Fix uneven margins, cramped text, and misaligned elements. - Keep it calm — remove decoration that isn't doing a job. Show the updated code and give me a 3-bullet summary of what you changed and why.
Your text reads like a generic AI wrote it — buzzwords, hedging, empty enthusiasm.
Here's the copy on my page:
[paste the headline, subhead, and body text]
Rewrite it to sound like a real builder talking to a real person. Rules:
- Lead with what the user actually gets.
- Cut buzzwords, hype, and empty phrases ("seamless", "revolutionary", "unlock", "elevate").
- Short sentences. Concrete nouns. Say the specific thing.
- Keep my product's actual value; don't invent claims.
Give me 2 versions: one plain and direct, one with a bit more personality.It looks fine on your laptop but breaks or feels cramped on a phone.
This component looks good on desktop but breaks on mobile: [paste the component or HTML/CSS] Make it work cleanly on a 375px-wide phone screen: - Find what overflows, overlaps, or gets too small to tap. - Fix it with a mobile-first approach; don't break the desktop layout. - Make sure tap targets are big enough and text stays readable (no tiny fonts). Show the updated code and list each issue you fixed.
Your UI works with a mouse on a good screen, but you haven't checked keyboard, contrast, or screen readers.
Here's a component/page I want to make accessible: [paste the markup/styles] Do an accessibility pass and fix the issues, without redesigning it: - Keyboard: can every interactive element be reached and used by keyboard alone, in a sensible order, with a visible focus state? - Semantics: are buttons, links, headings, and form labels real and correctly associated (not divs pretending to be buttons)? - Contrast: any text or UI that fails normal contrast guidelines? Give the failing pairs and a fix. - Images/icons: meaningful alt text where it matters, and hidden from screen readers where it's decorative. Show the updated code and a short list of what you fixed and why. Flag anything that needs a human to verify.
You're ready to charge and need a pricing page that's clear and easy to say yes to.
My product does: [describe it]. My users are: [who they are]. I want to charge: [your rough idea, e.g. one paid tier at $X/mo, or free + pro]. Design a simple pricing page: - Propose a tier structure (keep it to 2-3 options max) with what's in each and a recommended "most popular" pick. - Write the copy for each tier: name, price, one-line value, and the 3-5 things that matter most. - Suggest the single clearest call to action. - Flag anything that would make a buyer hesitate, and how to remove that friction. Keep it honest — no fake scarcity or dark patterns.
You want to prompt free users to upgrade at the right moment without being annoying.
I have a free tier and a paid tier. The paid tier unlocks: [list the key paid features]. A natural moment to nudge is: [describe when, e.g. when they hit a limit]. Write the upgrade nudge for that moment: - A short, specific message that names what they're about to get, not a generic "go pro". - Tie it to what they're doing right now so it feels helpful, not pushy. - Give me the button label too. - Offer one softer variant for people who dismiss it once. No guilt, no dark patterns. It should feel like a fair offer at a useful moment.
You don't know where to draw the line between your free and paid tiers.
My product does: [describe it and list the main features]. Help me split features into free vs. paid: - The free tier should deliver real value and show people why the product is good. - The paid tier should unlock things that map to getting more value or using it seriously. - Avoid crippling the free tier so badly that no one sticks around, and avoid giving away so much that no one upgrades. For each feature, say free or paid and why in one line. Then name the single feature most likely to drive upgrades, and where the natural upgrade moment is.
People reach your payment step but don't complete it, and you want to find what's stopping them.
Here's my path from "interested" to "paid": [describe each step a user goes through, from the pricing page to a completed purchase]. My product costs: [price]. My buyer is: [who they are]. Act as a conversion specialist. Find the friction that's costing me sales: - Walk through each step and flag where a motivated buyer is most likely to drop off, and why. - Point out anything that adds doubt at the moment of paying (unclear price, surprise steps, no trust signals, too many fields, no clear "what happens next"). - Give me the 3 highest-impact changes to make first, in order, with the reasoning. - Suggest one thing to measure so I know if a change actually helped. Keep it honest — improve clarity and trust, no dark patterns or fake urgency.