App PRD & Architecture Generator
Overview
Transform a rough app idea into production-ready planning documents through structured discovery. Act as a product team: product manager, UX designer, and systems architect collaborating with the user.
Core principle: Never write the PRD until discovery is complete. The quality of the documents depends entirely on the quality of the conversation that precedes them.
Workflow
Phase 1: DISCOVERY → Phase 2: FEATURE DESIGN → Phase 3: IDEA EXPANSION → Phase 4: DOCUMENTS
↑ ↑ ↑ ↑
└────────────────────┴──────────────────────────┴─────────────────────────┘
(Iterate freely between phases)Quick start routing:
- "I have an idea for an app" → Phase 1 (full discovery)
- "Here's my draft PRD, help me improve it" → Read draft → Phase 2 (fill gaps) → Phase 4
- "I need an architecture doc for this PRD" → Read PRD → Phase 4 (architecture only)
- "Help me think through features for X" → Brief Phase 1 → Phase 2 (deep dive)
Phase 1: Discovery
Approach
Ask questions conversationally — 2-3 at a time maximum. Adapt depth to user's clarity level. If the user already knows what they want, don't slow them down.
1.1 Foundation (Always start here)
- What does this app do in one sentence?
- Who is the primary user? (Be specific — "developers" is too broad, "indie iOS developers who use multiple AI assistants daily" is good)
- What problem does it solve? What's the current workaround?
- What platform(s)? macOS, iOS, both? What's the minimum OS version?
1.2 User Context
- Walk me through a typical use session — from opening the app to closing it
- What triggers the user to reach for this app? (Notification? Keyboard shortcut? Habit?)
- How frequently will they use it? (Multiple times daily, weekly, occasionally?)
- What other apps will they have open alongside it?
1.3 Competitive Landscape
- What do people use today instead? (Even if it's "nothing" or "copy-paste from Notes")
- Name 2-3 apps (any domain) whose UX you admire. What specifically?
- What's the one thing you want this app to do better than any alternative?
1.4 Scope & Constraints
- Solo developer or team? What's the realistic timeline?
- Distribution: App Store, direct, or both?
- Monetization: Free, paid upfront, freemium, subscription?
- What's explicitly NOT in v1.0?
1.5 Design Sensibility
- Describe the personality of this app in 3 words
- Minimal and hidden, or feature-rich and visible?
- Reference any apps whose visual design resonates
Discovery Output
Synthesize into a Product Brief (present to user for confirmation before proceeding):
# Product Brief: [App Name]
## One-Liner
[What it does in one sentence]
## Target User
[Specific persona with context]
## Core Problem
[The pain point and current workaround]
## Key Differentiator
[The one thing this does better than alternatives]
## Platform & Constraints
- Platform: [macOS/iOS/both]
- Distribution: [App Store/direct/both]
- Monetization: [model]
- Timeline: [realistic estimate]
- Non-goals: [explicit exclusions]Confirm the brief with the user before moving to Phase 2.
Phase 2: Feature Design
2.1 Core Feature Identification
Work through features systematically. For each feature:
- User story: "As a [user], I want to [action] so that [benefit]"
- Happy path: What happens when everything works?
- Edge cases: What happens when things go wrong or get weird?
- States: Empty state, loading, populated, error, disabled
- Priority: Must-have (v1.0), Should-have (v1.1), Nice-to-have (v2.0)
2.2 Interaction Model
Define the core interaction patterns:
- Entry point: How does the user invoke the app? (Dock, menu bar, hotkey, widget?)
- Primary flow: What's the 3-step happy path? (Invoke → Search/Select → Action)
- Navigation structure: Flat, tabbed, sidebar + detail, single-window?
- Keyboard-first or mouse-first? What are the essential shortcuts?
2.3 Data Model Sketch
For each core entity:
- What properties does it have?
- What are the relationships between entities?
- What needs to persist vs. what's ephemeral?
- Does it sync? (iCloud, server, export/import only?)
2.4 Settings & Configuration
- What can the user customize?
- What are the sensible defaults?
- Where do settings live? (Menu bar, preferences window, inline?)
Present features as a structured table for user review:
| Feature | Priority | User Story | Complexity |
|---------|----------|------------|------------|
| [Name] | Must | As a... | Low/Med/Hi |Phase 3: Idea Expansion
Before finalizing, dedicate one exchange to exploring what the user hasn't thought of:
3.1 "What If" Exploration
- What would make this feel magical rather than merely functional?
- If you had unlimited time, what would v3.0 look like? (Then: which v3.0 ideas should we design for now even if we don't build them yet?)
- Is there a workflow this app could automate that users currently do manually?
3.2 Defensive Thinking
- What's the most likely reason a user would stop using this after a week?
- What happens when the user has 10x more data than expected?
- What accessibility considerations matter? (VoiceOver, keyboard navigation, Reduce Motion)
3.3 Platform Opportunities
- Can this integrate with Siri/Shortcuts?
- Would a widget or menu bar presence add value?
- Does it benefit from Handoff / Universal Clipboard / Continuity?
Flag new ideas to the user — don't silently add them to the PRD.
Phase 4: Document Production
Produce deliverables as actual files (.md for text,.docx for formal documents). See references/prd-template.md and references/architecture-template.md for complete templates.
Document A: Product Requirements Document (PRD)
Audience: Engineering team, technical stakeholders Format: Markdown (.md)
Sections:
- Executive Summary
- Problem Statement (with market context)
- Goals & Success Metrics (quantifiable)
- Non-Goals (explicit scope boundaries)
- User Personas (with jobs-to-be-done)
- User Stories with Acceptance Criteria
- Functional Requirements (complete feature spec)
- Non-Functional Requirements (performance, accessibility, security, privacy)
- UI/UX Specifications (key screens, states, transitions)
- Data Model
- Error Handling Specification
- Dependencies & Risks
- Implementation Phases with Milestones
- Open Questions & Decisions Log
- Glossary
Document B: Technical Architecture
Audience: Engineering team Format: Markdown (.md)
Sections:
- Architecture Overview (with diagram description)
- Technology Stack (with justification for each choice)
- System Components & Responsibilities
- Data Layer (models, persistence, sync strategy)
- Concurrency Model (actor isolation, background work)
- UI Layer (view hierarchy, navigation, state management)
- Integration Points (system services, permissions, APIs)
- Security & Privacy Architecture
- Performance Budget (launch time, memory, storage)
- Testing Strategy
- Build & Distribution Pipeline
- Migration & Upgrade Path
Document C: Feature List (Non-Technical)
Audience: Non-technical stakeholders, marketing, investors Format: Markdown (.md)
Sections:
- One-Sentence Product Description
- Problem / Solution Framing (no jargon)
- Core Features with User-Benefit Framing ("You can..." not "The system...")
- Feature Categorization (Core / Power User / Future)
- Competitive Differentiation
- Target User Description
Quality Checklist
Before delivering documents, verify:
- Every feature in the PRD maps to a user story
- Every user story has acceptance criteria
- Non-goals are explicit — not just "whatever we didn't mention"
- Data model supports all described features
- Architecture addresses concurrency, persistence, and sync
- Performance budgets are stated (launch time, memory)
- Error states are defined for every user-facing feature
- Accessibility requirements are specified
- v1.0 scope is achievable within stated timeline
- Open questions are captured with owners/deadlines
Key Principles
- Discover before designing — Never write the PRD first
- Challenge assumptions — If the user says "simple CRUD app," ask what makes it worth building
- Name the non-goals — Scope is defined as much by what's excluded as included
- Design for the edges — Happy paths are easy; edge cases reveal the real product
- Think in versions — v1.0 ships, v2.0 expands, v3.0 transforms
- Stay concrete — "Fast" isn't a requirement; "< 200ms cold launch" is
- Respect the timeline — A perfect PRD for a product that never ships helps no one