No-Code Product Build
Prompt Library

You are a Senior PM helping someone build a product from scratch. 
Ask only what you need to write a clear, 1-paragraph problem statement.

Ask the user these questions one group at a time (don't dump all at once):

GROUP 1 — The Problem:
1. What problem are you solving? Describe it in plain language.
2. Who experiences this problem? Be specific (age, role, context).
3. How do they solve it today, and what's wrong with that solution?

GROUP 2 — The Product:
4. What is your product in one sentence?
5. What is the ONE thing it does better than anything else?
6. Is this a web app, mobile app, tool, or platform?

GROUP 3 — Constraints:
7. Any hard constraints? (Budget, timeline, technology limits)
8. Do you have a no-code tool already in mind? (Lovable, Bubble, Webflow, etc.)
9. Who are your 2–3 direct competitors or reference products you admire?

After the user answers, synthesize into:
- Problem Statement (2–3 sentences)
- Product Hypothesis: "We believe [USER] will [DO X] because [REASON]."
- Top 3 assumptions to validate

[REPLACE: Add your product idea below the prompt when pasting into your AI tool]

You are a PM running a feature scoping session for [PROJECT_NAME].

Context: [PASTE PROBLEM STATEMENT FROM P1-01]

Now help define the MVP scope. Follow this process:

STEP 1 — Brain dump:
Ask: "List every feature you can imagine for this product. Don't filter. Go."
Capture all ideas without judgment.

STEP 2 — Ruthless triage:
For each feature, categorize as:
- MUST-HAVE: Without this, the product doesn't work.
- NICE-TO-HAVE: Adds value but not critical for launch.
- FUTURE: Great idea, wrong time.
- CUT: Scope creep. Kill it.

STEP 3 — MVP definition:
State clearly: "The MVP ships when [USER] can [CORE_ACTION] end-to-end."
List only MUST-HAVE features in the MVP.

STEP 4 — Success metrics:
Define 1 North Star Metric + 2 supporting KPIs:
- North Star: [What single number tells us this is working?]
- KPI 1: [Leading indicator]
- KPI 2: [Engagement or retention signal]

Output: Finalized MVP Feature List + Metrics Document
[PROJECT_NAME]: Replace with your product name
[PASTE PROBLEM STATEMENT FROM P1-01]: Paste output from previous step

Using the outputs from P1-01 and P1-02, generate a clean, 1-page Product Brief.

FORMAT:

# [PROJECT_NAME] — Product Brief

## Problem
[2 sentences. What's broken, for whom, and why now.]

## Solution
[1 sentence. What this product does.]

## Target User
[Name the persona. Role, context, pain point, current workaround.]

## MVP Scope
Must-Have:
- [Feature 1]
- [Feature 2]
- [Feature 3]

Out of Scope (v1):
- [Feature A]
- [Feature B]

## Success Metrics
- North Star: [Metric]
- KPI 1: [Metric]
- KPI 2: [Metric]

## Constraints
- Timeline: [X hours / days]
- No-code tools: [Tool choices]
- Platforms: [Web / iOS / Android / All]

## Approval Gate — Phase 1 → Phase 2:
☐ Problem statement is specific and validated
☐ MVP features are under 5
☐ North Star metric is measurable
☐ No-code tool stack is confirmed
☐ User signed off on this brief

[PROJECT_NAME]: Replace with your product name

You are a Product Designer starting the design phase for [PROJECT_NAME].
Before proposing any design, gather the user's visual preferences.

Ask these questions (one group at a time):

GROUP 1 — Feel:
1. Pick a vibe: Clean/minimal | Bold/confident | Warm/friendly | Technical/precise | Other
2. Name 2–3 apps or websites whose design you love and why.
3. Name 1 app whose design you hate. What bothers you about it?

GROUP 2 — Visual:
4. Light mode, dark mode, or user's choice?
5. Do you have a brand color or palette in mind? (Hex or description)
   If not, describe the emotion the product should evoke.
6. Any font preferences? (If none, say "system-default" and I'll suggest.)
7. Do you have reference images or screenshots? Please upload them now.

GROUP 3 — Constraints:
8. Any brand guidelines to follow? (Logo, colors, dos/don'ts)
9. Accessibility requirements? (Standard WCAG AA, or stricter?)
10. Will this be used on mobile primarily, desktop, or both equally?

After collecting answers, summarize in a Style Brief:
- Design keywords (e.g., "minimal, precise, dark, monochrome with one accent")
- Color palette (3 colors max: background, text, accent)
- Typography direction
- Inspiration references
- Anti-patterns to avoid

[PROJECT_NAME]: Replace with your product name

Using the Style Brief from P2-01, generate a minimal Design System Brief for [PROJECT_NAME].

OUTPUT FORMAT:

## Color Tokens
- Background: [HEX]
- Surface: [HEX]
- Text Primary: [HEX]
- Text Secondary: [HEX]
- Accent: [HEX]
- Error: [HEX]
- Success: [HEX]
- Border: [HEX]

## Typography
- Display: [Font name, weight, size — used for headings]
- Body: [Font name, weight, size — used for paragraphs]
- Mono: [Font name — used for code or data]
- Scale: H1 / H2 / H3 / Body / Caption / Label

## Spacing
- Base unit: 4px
- Scale: 4 / 8 / 12 / 16 / 24 / 32 / 48 / 64

## Component Patterns
- Button (Primary / Secondary / Ghost / Destructive)
- Input field (default, focused, error, disabled)
- Card
- Navigation bar
- Modal/Sheet

## Accessibility
- Minimum contrast ratio: 4.5:1 (WCAG AA)
- Touch target minimum: 44×44px
- Focus visible: always on

## Anti-patterns (from user input)
- [List what NOT to use: gradients, drop shadows, rounded corners, etc.]

[PROJECT_NAME]: Replace with your product name

Using the MVP Feature List (P1-02) and Design System Brief (P2-02), 
spec every screen for [PROJECT_NAME].

For EACH screen, output this template:

---
SCREEN: [Screen Name]
ROUTE: [URL or navigation path, e.g., /dashboard]
PURPOSE: [What the user accomplishes on this screen in 1 sentence]
USER ENTRY POINT: [How user gets here]
EXIT POINTS: [Where they go next]

LAYOUT:
- Header: [Nav, back button, title, actions]
- Body: [Main content area — describe layout]
- Footer: [Tab bar, CTA, pagination]

COMPONENTS:
- [Component 1]: [What it displays, what it does]
- [Component 2]: [What it displays, what it does]

DATA NEEDED:
- [Field 1: type, source]
- [Field 2: type, source]

INTERACTIONS:
- [Action → Result]: e.g., "Tap 'Add Task' → opens bottom sheet"
- [Action → Result]

STATES:
- Empty state: [What shows when there's no data]
- Loading state: [Skeleton or spinner]
- Error state: [What shows on failure]
- Filled state: [Normal view with data]

ACCEPTANCE CRITERIA:
☐ [Criterion 1]
☐ [Criterion 2]
---

Repeat for all screens. List all screens first, then spec each one.
[PROJECT_NAME]: Replace with your product name
[SCREENS]: List them — e.g., Onboarding, Home, Detail, Create, Profile, Settings]

Based on the following product requirements, recommend the best no-code tool stack
and explain why. Then give an implementation order.

PRODUCT CONTEXT:
- Product Brief: [PASTE FROM P1-03]
- MVP Features: [LIST FROM P1-02]
- Platform target: [Web / iOS / Android / All]
- User scale expected: [< 100 / 100–10K / 10K+]
- Does it need: Auth? [Y/N] | Database? [Y/N] | Real-time? [Y/N] | Payments? [Y/N]
  File uploads? [Y/N] | External APIs? [Y/N] | Custom domain? [Y/N]

EVALUATE THESE TOOLS:
Lovable, Bolt.new, v0, Webflow, Bubble, Glide, Softr, FlutterFlow, AppGyver/SAP,
Supabase (DB+Auth), Airtable, Firebase, Xano, Zapier, Make, Clerk

OUTPUT FORMAT:
1. Recommended primary builder + reason
2. Recommended database/backend tool + reason
3. Recommended auth solution + reason
4. Any integrations needed + tools for each
5. Known limitations of this stack
6. Backup option if primary doesn't work

[PASTE FROM P1-03]: Paste your finalized Product Brief
[LIST FROM P1-02]: Paste your MVP feature list

Build the [SCREEN_NAME] screen for [PROJECT_NAME] using [TOOL_NAME].

DESIGN TOKENS (apply globally):
- Background: [HEX]
- Text: [HEX]
- Accent: [HEX]
- Font: [FONT_NAME]
- Spacing unit: 8px

SCREEN SPEC:
[PASTE FULL SPEC FOR THIS SCREEN FROM P2-03]

BUILD INSTRUCTIONS:
1. Use only the components defined in the design system.
2. Use static/mock data for now. No backend connections yet.
3. Make it fully responsive: mobile (375px), tablet (768px), desktop (1280px).
4. Implement all 4 states: empty, loading, error, filled.
5. No decorative shadows or gradients unless in spec.
6. Navigation between screens must be wired up with placeholder routes.

WHAT TO OUTPUT:
- Working screen component
- Component list used
- Any design tokens or variables defined
- Navigation connections

After this screen is built, pause and await review before building the next screen.

[SCREEN_NAME]: e.g., Dashboard, Onboarding, Task Detail
[PROJECT_NAME]: Your product name
[TOOL_NAME]: e.g., Lovable, Bolt.new, v0
[PASTE FULL SPEC]: Paste screen spec from P2-03

All screens for [PROJECT_NAME] have been built. Now audit the front-end build.

RESPONSIVE AUDIT (test each breakpoint):
For each screen at 375px / 768px / 1280px:
☐ No horizontal overflow
☐ Typography scales correctly (no tiny text on mobile)
☐ Touch targets ≥ 44px on mobile
☐ Images/icons resize properly
☐ Navigation is accessible on all breakpoints

NAVIGATION AUDIT:
List all screens and verify:
☐ Every screen is reachable from the app
☐ Back navigation works correctly
☐ Deep links resolve to the right screen
☐ No broken routes or dead ends

DESIGN CONSISTENCY AUDIT:
☐ Color tokens used consistently (no hardcoded hex in individual components)
☐ Font scale applied globally
☐ Spacing is consistent with 8px grid
☐ Button styles are consistent across screens
☐ Empty / loading / error states present on all data-dependent screens

OUTPUT:
- Audit report (pass / fail per item)
- List of issues found with screen reference
- Priority: critical (blocks UX) / minor (visual polish)
- Estimated fix time per issue

[PROJECT_NAME]: Replace with your product name

Based on the MVP features and screen specs for [PROJECT_NAME], 
design a minimal data model. Use [SUPABASE / AIRTABLE / FIREBASE].

INSTRUCTIONS:
1. List all entities (tables/collections) the product needs.
2. For each entity, define:
   - Table name
   - Fields: name | type | required | description
   - Relationships: FK references, one-to-many, many-to-many
   - Row-level security rules (who can read/write this row)
3. Keep it minimal. Only create what's needed for MVP.
4. Flag any data that is PII (personally identifiable information).

OUTPUT FORMAT:

## Table: [TABLE_NAME]
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| id | uuid | yes | Primary key |
| created_at | timestamp | yes | Auto-generated |
| [field] | [type] | [y/n] | [description] |

Relationships:
- [TABLE] → [OTHER_TABLE]: [one-to-many / many-to-many]

RLS Rules:
- Read: [who can read]
- Write: [who can write]
- Delete: [who can delete]

PII Fields: [list any]

---
Repeat for all tables. Then generate SQL (if Supabase) or schema setup instructions.

[PROJECT_NAME]: Replace with your product name
[SUPABASE / AIRTABLE / FIREBASE]: Choose your database tool

Set up authentication and permissions for [PROJECT_NAME] using [AUTH_TOOL].

AUTH REQUIREMENTS:
- Auth methods needed: [Email/Password | Google OAuth | Magic Link | Phone OTP | Guest]
- User roles: [e.g., Admin, Member, Guest — describe what each can do]
- Protected routes: [List screens that require auth]
- Public routes: [List screens accessible without auth]

SETUP INSTRUCTIONS:
1. Configure auth provider in [AUTH_TOOL].
2. Create a users table with: id, email, role, created_at, [custom fields].
3. Define redirect behavior:
   - On successful login → [SCREEN]
   - On logout → [SCREEN]
   - On unauthorized access → [SCREEN]
4. Implement session persistence (remember me / token expiry rules).
5. Set up email templates for: verification, password reset, welcome.

PERMISSION MATRIX:
For each role, what can they do?
| Action | Admin | Member | Guest |
|--------|-------|--------|-------|
| [Action 1] | ✓ | ✓ | ✗ |
| [Action 2] | ✓ | ✗ | ✗ |

SECURITY CHECKLIST:
☐ API keys stored in environment variables (not in frontend code)
☐ Row-level security enabled on all tables
☐ Email verification required before access
☐ Password strength requirements set (min 8 chars, 1 special char)
☐ Session timeout configured

[PROJECT_NAME]: Replace with your product name
[AUTH_TOOL]: e.g., Supabase Auth, Clerk, Firebase Auth
[USER ROLES]: Define your own — Admin/Member/Guest is just an example

Design the automation and API integration layer for [PROJECT_NAME].

INTEGRATIONS NEEDED:
[List from product brief — e.g., Email notifications, Stripe payments, 
Slack alerts, Google Sheets sync, Twilio SMS, OpenAI API, etc.]

For each integration, output:

---
INTEGRATION: [Name]
TOOL: [Zapier / Make / n8n / Native no-code connector]
TRIGGER: [What event starts this — e.g., "New row in Supabase"]
ACTION: [What happens — e.g., "Send email via SendGrid"]
DATA PASSED: [Fields mapped from trigger to action]
ERROR HANDLING: [What happens if it fails]
TEST CASE: [How to verify it's working]
---

After all automations are listed:
☐ Test each automation with a real trigger
☐ Confirm data is passing correctly between steps
☐ Set up error notifications (email or Slack alert on failure)
☐ Document webhook URLs and store securely

[PROJECT_NAME]: Replace with your product name
[List integrations]: Email? Payments? Analytics? Notifications?

Generate a complete test plan for [PROJECT_NAME] from the screen specs and acceptance criteria.

TEST COVERAGE REQUIRED:
1. Happy path (primary user journey end-to-end)
2. Edge cases (empty inputs, max length, no data states)
3. Error states (network failure, invalid input, auth failure)
4. Responsive (375px, 768px, 1280px)
5. Cross-browser (Chrome, Safari, Firefox minimum)
6. Auth flows (signup, login, password reset, logout, session expiry)

OUTPUT FORMAT (per test case):

| ID | Screen | Test | Steps | Expected | Priority |
|----|--------|------|-------|----------|----------|
| T01 | [Screen] | [What's being tested] | 1. Do X 2. Do Y | [Expected result] | Critical/Major/Minor |

ACCEPTANCE CRITERIA REVIEW:
For each screen's acceptance criteria (from P2-03), write a corresponding test case.

BUG LOG TEMPLATE:
| BUG-ID | Screen | Description | Steps to Reproduce | Severity | Status |
|--------|--------|-------------|-------------------|----------|--------|

SIGN-OFF CHECKLIST:
☐ All critical path tests passing
☐ No critical or high severity bugs open
☐ All 4 states working on all screens
☐ Auth flows working end-to-end
☐ Responsive on 3 breakpoints
☐ Performance: page load under 3 seconds

[PROJECT_NAME]: Replace with your product name

Run a pre-launch security audit for [PROJECT_NAME].

AUDIT AREAS:

1. API Key Exposure
   ☐ No API keys in frontend JS code
   ☐ All secrets in environment variables
   ☐ No keys in git history

2. Database Security
   ☐ RLS enabled on ALL tables
   ☐ No tables publicly readable without auth
   ☐ Admin operations require admin role check
   ☐ No direct DB URL exposed in frontend

3. Auth Security
   ☐ Session tokens expire correctly
   ☐ Logout invalidates session on server
   ☐ Password reset links expire in 1 hour
   ☐ Email verification enforced

4. Input Validation
   ☐ All form inputs sanitized
   ☐ File upload types restricted (if applicable)
   ☐ Max input lengths enforced
   ☐ SQL injection not possible (parameterized queries)

5. Data Privacy
   ☐ PII fields identified and noted
   ☐ Data deletion workflow exists (if required by GDPR)
   ☐ Privacy policy page exists (if collecting personal data)

RISK MATRIX OUTPUT:
| Vulnerability | Risk Level | Mitigation | Status |
|---------------|------------|------------|--------|
| [Issue] | High/Med/Low | [Fix] | Open/Resolved |

All HIGH risks must be resolved before launch.

[PROJECT_NAME]: Replace with your product name

Fix the following bug in [PROJECT_NAME] and verify the fix.

BUG REPORT:
- Screen: [SCREEN_NAME]
- Description: [What's wrong]
- Steps to reproduce: [1. Do X, 2. Do Y, 3. See Z]
- Expected behavior: [What should happen]
- Severity: [Critical / Major / Minor]

FIX INSTRUCTIONS:
1. Identify the root cause (not just the symptom).
2. Fix it in the no-code tool. Do NOT introduce new dependencies.
3. Do NOT break other screens while fixing this one.
4. After fixing, test:
   ☐ Bug is gone
   ☐ Adjacent screens still work
   ☐ Fix works on mobile (375px) too

VERIFICATION:
State: "Bug [BUG-ID] is fixed. Verified by: [test steps]. No regressions observed on: [screens checked]."

Update the bug log status to: Resolved.

[SCREEN_NAME]: Screen where the bug occurs
[What's wrong, repro steps]: Fill in from your bug log

Run the pre-launch deployment checklist for [PROJECT_NAME] on [NO_CODE_TOOL].

PRODUCTION ENVIRONMENT:
☐ Production environment variables set (not dev keys)
☐ Custom domain configured and SSL active
☐ 404 and error pages set up
☐ Favicon and app icon added
☐ Meta tags (title, description, OG image) set

PERFORMANCE:
☐ Images compressed and optimized
☐ Lazy loading on below-the-fold content
☐ Load time < 3s on mobile (test with PageSpeed Insights)
☐ No unnecessary third-party scripts

ANALYTICS & MONITORING:
☐ Google Analytics 4 or PostHog installed
☐ Error monitoring set up (Sentry or tool-native)
☐ Uptime monitoring configured (UptimeRobot — free)
☐ North Star metric event tracked

LEGAL & COMPLIANCE:
☐ Privacy policy page live (if collecting personal data)
☐ Terms of service page live (if needed)
☐ Cookie consent banner (if using tracking in EU)

BACKUPS:
☐ Database backup schedule configured
☐ Version history / snapshots taken before launch

FINAL SIGN-OFF:
☐ User has reviewed live staging environment
☐ All Phase 5 sign-offs confirmed
☐ Support/feedback mechanism live (Tally form or email)
☐ Ready to launch 🚀

[PROJECT_NAME]: Replace with your product name
[NO_CODE_TOOL]: Your builder — Lovable, Webflow, Bubble, etc.

Build a minimal, high-converting landing page for [PROJECT_NAME] using [TOOL — Webflow / Framer / Lovable].

PRODUCT CONTEXT:
- What it does: [1 line from Product Brief]
- Target user: [Persona from P1]
- Primary CTA: [Sign Up / Start Free / Get Access / Waitlist]
- Design tokens: [Same as product — Background HEX, Text HEX, Accent HEX, Font]

SECTIONS (in order):
1. Hero — Headline, subheadline, CTA button, hero image/animation
2. Problem — "If you've ever..." empathy statement (3 pain points max)
3. Solution — How [PROJECT_NAME] fixes it (3 features, icon + description format)
4. Social proof — Logos, testimonials, or "used by X people" counter
5. How it works — 3-step visual process
6. Final CTA — Repeat the primary CTA with urgency
7. Footer — Links, copyright, social, privacy policy

COPY GUIDELINES:
- Headline: Outcome-focused, not feature-focused. e.g., "Ship faster" not "A fast build tool"
- No jargon. Write at 8th-grade reading level.
- Every section has ONE job. Don't mix messages.

TECHNICAL:
- Link CTA to: [PRODUCT_URL / signup page]
- Add Google Analytics tracking on CTA clicks
- Responsive: mobile-first

[PROJECT_NAME, TOOL, PRODUCT_URL]: Fill in your details
[Design tokens]: Paste from P2-02

Create a post-launch maintenance and scaling playbook for [PROJECT_NAME].

MONITORING SETUP:
1. Uptime: UptimeRobot — alert on [email/Slack] if site is down > 2 min
2. Errors: Sentry (or tool-native error logs) — alert on any unhandled exception
3. Performance: Weekly Google PageSpeed check, alert if score drops below 80
4. Analytics: Weekly review of North Star metric ([METRIC]) in GA4/PostHog

VERSIONING:
- Before every major change: take a snapshot/backup of the current build
- Maintain a changelog: [Date | Change | Who]
- Tag releases: v1.0 (launch), v1.1, v1.2 etc.

SCALING TRIGGERS:
At what point do you upgrade?
| Metric | Threshold | Action |
|--------|-----------|--------|
| Users | > 1,000 MAU | Upgrade DB tier |
| Storage | > 80% used | Add capacity |
| API calls | Near rate limit | Upgrade plan or cache |
| Load time | > 4s on mobile | Optimize assets |

COMMON MAINTENANCE TASKS (monthly):
☐ Review and rotate API keys
☐ Check for unused automations / zombie Zapier zaps
☐ Review user feedback and triage to backlog
☐ Run security audit (P5-02) again
☐ Check for no-code tool updates and apply

FEEDBACK LOOP:
1. Embed a feedback widget (Tally / Typeform / HotJar poll)
2. Review weekly. Map to: Bug / Feature request / UX issue
3. Prioritize using: Impact × Effort matrix
4. Ship a small improvement every 2 weeks

[PROJECT_NAME]: Replace with your product name
[METRIC]: Your North Star metric from P1-02