Professional Project Documentation Generator

Prompt preview

Generate a complete, professional project document for a software, SaaS, AI, education, business, website, mobile application, internal tool, or technology product.

The output must read like a document prepared by an experienced product manager, software architect, business analyst, and technical documentation specialist.

Cross-Model Prompt - Designed to work with ChatGPT, Claude, Gemini, and other modern AI models.

Do not produce generic AI filler. Do not simply expand the user's notes into long paragraphs. Analyze the project first, identify missing areas, resolve reasonable assumptions, and produce a structured document that could be used for planning, development, internal review, client discussion, or project approval.

---

## INPUT VARIABLES

Replace the values below with the project information.

PROJECT_NAME = {{project_name}}
PROJECT_TYPE = {{project_type}}
PROJECT_OWNER_OR_COMPANY = {{project_owner}}
PROJECT_URL = {{project_url}}
PROJECT_DESCRIPTION = {{project_description}}
PROBLEM_TO_SOLVE = {{problem_to_solve}}
TARGET_USERS = {{target_users}}
TARGET_MARKET = {{target_market}}
CORE_FEATURES = {{core_features}}
USER_ROLES = {{user_roles}}
PLATFORMS = {{platforms}}
PREFERRED_TECH_STACK = {{preferred_tech_stack}}
HOSTING_REQUIREMENTS = {{hosting_requirements}}
DATABASE_REQUIREMENTS = {{database_requirements}}
THIRD_PARTY_SERVICES = {{third_party_services}}
AI_REQUIREMENTS = {{ai_requirements}}
SECURITY_REQUIREMENTS = {{security_requirements}}
PAYMENT_REQUIREMENTS = {{payment_requirements}}
BUSINESS_MODEL = {{business_model}}
PROJECT_BUDGET = {{project_budget}}
DEADLINE = {{deadline}}
CURRENT_STATUS = {{current_status}}
KNOWN_CONSTRAINTS = {{known_constraints}}
REFERENCE_WEBSITES_OR_PRODUCTS = {{reference_products}}
ADDITIONAL_NOTES = {{additional_notes}}

If a variable is not provided, do not invent a specific fact.

Instead:

1. Infer only what is reasonably obvious from the project description.
2. Mark important assumptions clearly as "Assumption".
3. Identify information that should be confirmed.
4. Continue producing the document instead of stopping unnecessarily.

---

# REQUIRED OUTPUT

Create the document using the following structure.

## 1. Executive Summary

Explain:

* What the project is
* What problem it solves
* Who it is for
* Why it is useful
* What the proposed solution does
* What makes it different

Keep this section concise and executive-level.

---

## 2. Project Overview

Include:

* Project name
* Project type
* Owner/company
* Target platform
* Project status
* Proposed technology
* Business model
* Primary objective

---

## 3. Problem Statement

Clearly define the problem.

Explain:

* Current situation
* User pain points
* Existing limitations
* Inefficiencies
* Market opportunity
* Why the problem is worth solving

Do not manufacture market statistics.

If evidence is unavailable, describe the opportunity qualitatively.

---

## 4. Proposed Solution

Describe how the product solves the problem.

Explain the product from the user's perspective before describing the technical implementation.

Include:

* Core solution
* Main workflow
* Key user interactions
* Major product benefits
* Differentiating capabilities

---

## 5. Target Audience

Define the primary and secondary users.

For each important user group explain:

* Who they are
* Their needs
* Their problems
* How they use the product
* What outcome they expect

---

## 6. User Roles and Permissions

Create a clear role model.

For each role specify:

* Role name
* Purpose
* Access level
* Main actions
* Restricted actions

Do not create unnecessary roles.

Use least-privilege principles.

---

## 7. Core Features

Break the product into logical feature modules.

For every major feature provide:

### Feature Name

**Purpose**

Explain why the feature exists.

**User Flow**

Describe how the user interacts with it.

**Functional Requirements**

List the expected behavior.

**Validation**

Explain important validation rules.

**Edge Cases**

Identify important failure scenarios.

**Dependencies**

Identify related modules or external services.

---

## 8. Functional Requirements

Convert the project concept into implementation-ready requirements.

Use requirement IDs such as:

FR-001
FR-002
FR-003

Each requirement must contain:

* ID
* Requirement
* Priority
* Description
* Acceptance criteria

Use priorities:

* Critical
* High
* Medium
* Low

Avoid vague requirements such as:

"System should be user friendly."

Instead write measurable requirements such as:

"Authenticated users must be able to save lesson progress and resume from the last completed checkpoint."

---

# 9. Non-Functional Requirements

Define:

### Performance

* Page-load expectations
* API response expectations
* Caching
* Asset optimization

### Scalability

* Expected growth
* Database considerations
* Stateless architecture
* Background processing where required

### Security

* Authentication
* Authorization
* Input validation
* Rate limiting
* CSRF protection where applicable
* XSS protection
* SQL injection protection
* Secure secrets
* File-upload security
* Logging
* Abuse prevention

### Reliability

* Error handling
* Backup strategy
* Monitoring
* Recovery

### Accessibility

Consider:

* Keyboard navigation
* Semantic HTML
* Screen readers
* Contrast
* Focus states
* Responsive layouts

### Maintainability

Consider:

* Modular architecture
* Type safety
* Code standards
* Documentation
* Testing

---

# 10. Technical Architecture

Design an appropriate architecture based on the project.

Explain:

* Frontend
* Backend
* Database
* Authentication
* APIs
* Storage
* Third-party integrations
* Background jobs
* Caching
* Deployment
* Monitoring

Do not force a technology merely because it appears in the input.

If the requested stack is unsuitable for a requirement, explain the issue and recommend a better approach.

---

# 11. Technology Stack

Create a table:

| Layer          | Technology | Reason |
| -------------- | ---------- | ------ |
| Frontend       | ...        | ...    |
| Backend        | ...        | ...    |
| Database       | ...        | ...    |
| Authentication | ...        | ...    |
| Storage        | ...        | ...    |
| Hosting        | ...        | ...    |
| Monitoring     | ...        | ...    |

Only recommend technologies appropriate for the project's actual requirements.

---

# 12. Database Design

If the project requires persistent data, design the primary entities.

For every entity provide:

* Table/entity name
* Purpose
* Important fields
* Relationships
* Indexing considerations

Identify:

* Primary keys
* Foreign keys
* Unique constraints
* Important indexes

Do not over-normalize unnecessarily.

---

# 13. API Design

If APIs are required, define important endpoints.

Example:

GET    /api/...
POST   /api/...
PATCH  /api/...
DELETE /api/...

For each important endpoint specify:

* Purpose
* Authentication requirement
* Request
* Response
* Validation
* Error cases

Do not create APIs that the product does not actually need.

---

# 14. Authentication and Authorization

Define:

* Registration
* Login
* Logout
* Password recovery
* Session management
* Role-based access
* Permission checks
* Account protection
* Rate limiting

Never rely only on frontend permission checks.

Authorization must be enforced server-side.

---

# 15. Security Architecture

Perform a practical security review.

Identify risks such as:

* Authentication attacks
* Authorization bypass
* XSS
* SQL injection
* CSRF
* Brute-force attacks
* Credential abuse
* API abuse
* File-upload attacks
* SSRF
* Path traversal
* Sensitive information exposure
* Bot/spam abuse
* Untrusted code execution

For every relevant risk provide:

**Threat → Protection → Implementation approach**

Do not claim that an application is "100% secure."

---

# 16. AI Architecture

If AI is part of the project, define:

* AI use cases
* Model/provider requirements
* Prompt architecture
* Input validation
* Output validation
* Token/cost controls
* Rate limits
* Context management
* Data privacy
* Failure handling
* Abuse prevention

AI should be treated as an external dependency, not as a guaranteed source of truth.

---

# 17. User Experience

Describe the primary user journey.

Use:

Landing Page
      ↓
Registration / Entry
      ↓
Dashboard
      ↓
Primary Action
      ↓
Result
      ↓
Progress / Next Step

Explain:

* Navigation
* Information hierarchy
* Mobile experience
* Empty states
* Loading states
* Error states
* Success states
* Onboarding

---

# 18. Admin / Management System

If an admin area is required, define:

* Dashboard
* User management
* Content management
* Settings
* Reports
* Moderation
* Logs
* Permissions
* Configuration

Separate administrative functionality from the public user experience.

---

# 19. Project Workflow

Define the recommended development sequence.

Example:

Discovery
↓
Architecture
↓
Database
↓
Authentication
↓
Core Features
↓
Integrations
↓
Testing
↓
Security Review
↓
Deployment
↓
Monitoring

Explain dependencies between phases.

---

# 20. Development Phases

Divide the project into:

### Phase 1 - Foundation

### Phase 2 - Core Product

### Phase 3 - Advanced Features

### Phase 4 - Testing & Security

### Phase 5 - Launch

### Phase 6 - Post-Launch

For every phase identify:

* Objectives
* Deliverables
* Dependencies
* Completion criteria

---

# 21. MVP Definition

Clearly separate:

### Must Have

Features required for launch.

### Should Have

Important but can follow shortly after launch.

### Could Have

Useful future features.

### Not Now

Features that should deliberately be excluded from the MVP.

Do not allow scope creep.

---

# 22. Testing Strategy

Define:

* Unit testing
* Integration testing
* API testing
* End-to-end testing
* Authentication testing
* Permission testing
* Security testing
* Responsive testing
* Browser testing
* Performance testing
* Regression testing

Include critical test scenarios.

---

# 23. Deployment Strategy

Describe:

* Environment structure
* Development
* Staging
* Production
* Environment variables
* Secrets
* Build process
* Database migrations
* Deployment checks
* Rollback strategy

Never expose secrets in source code.

---

# 24. Cost Strategy

Analyze the lowest-cost realistic architecture.

Separate:

### Development Cost

### Hosting Cost

### Database Cost

### Third-Party Services

### AI/API Cost

### Domain/Email Cost

### Future Scaling Cost

If a service has a free tier, do not assume unlimited usage.

State:

"Verify current provider pricing and commercial-use terms before production launch."

---

# 25. Scalability Plan

Explain what should happen when the product grows from:

* 100 users
* 1,000 users
* 10,000 users
* 100,000+ users

Do not prematurely introduce enterprise infrastructure.

Recommend scaling only when actual usage requires it.

---

# 26. Analytics

Define useful product metrics.

Examples:

* Registrations
* Active users
* Feature usage
* Conversion
* Completion rate
* Retention
* Drop-off
* Errors
* Revenue where applicable

Do not collect unnecessary personal data.

---

# 27. Business Model

If applicable, describe:

* Free tier
* Paid tier
* Subscription
* One-time purchase
* Institutional licensing
* Advertising
* Marketplace
* Service revenue

Explain the relationship between the business model and product architecture.

---

# 28. Risks

Create a table:

| Risk | Probability | Impact | Mitigation |
| ---- | ----------- | ------ | ---------- |

Include technical, business, security, operational and user-experience risks.

---

# 29. Future Roadmap

Recommend future features based on the product's actual direction.

Do not add random "AI-powered" features simply to make the roadmap look advanced.

Prioritize features by:

* User value
* Business value
* Technical complexity
* Dependency
* Cost

---

# 30. Acceptance Criteria

Define the conditions required to consider the project ready for launch.

Examples:

* Critical workflows work end-to-end.
* Authentication works correctly.
* Authorization cannot be bypassed through the frontend.
* Critical security controls are implemented.
* Responsive layouts work on supported devices.
* Production deployment succeeds.
* Monitoring is operational.
* Backups/recovery are configured where required.
* No known critical defects remain.

---

# 31. Open Questions and Assumptions

At the end, list:

### Confirmed

Information explicitly provided by the user.

### Assumptions

Reasonable assumptions made during planning.

### Open Questions

Information that should be confirmed before implementation.

Do not hide assumptions inside the document.

---

# 32. Final Recommendation

Conclude with:

* Recommended architecture
* Recommended MVP
* Most important product decision
* Biggest technical risk
* Biggest business risk
* Recommended next step

The conclusion must be practical rather than promotional.

---

# PROMPT ENGINEERING REQUIREMENTS

The generated project document must follow these principles.

1. Think like a senior product architect before writing.
2. Do not blindly follow technically incorrect requirements.
3. Do not invent facts, statistics, integrations or certifications.
4. Distinguish facts from assumptions.
5. Prefer simple architecture over unnecessary complexity.
6. Design for the actual MVP rather than hypothetical enterprise scale.
7. Identify security implications of every sensitive feature.
8. Treat third-party services as dependencies with cost and availability considerations.
9. Do not claim free tiers are unlimited.
10. Do not claim security is absolute.
11. Do not claim accreditation or regulatory approval without evidence.
12. Use measurable acceptance criteria.
13. Avoid repetitive paragraphs.
14. Avoid generic AI phrases such as "cutting-edge", "revolutionary", "seamless", "robust", and "next-generation" unless the claim is specifically justified.
15. Prefer precise technical language.
16. Do not make the document unnecessarily long just to increase word count.
17. Prioritize actionable requirements over marketing language.

---

# OUTPUT QUALITY CHECK

Before finalizing, silently verify:

[ ] Every major product requirement is covered.
[ ] Assumptions are clearly identified.
[ ] No unsupported facts were invented.
[ ] Functional requirements are testable.
[ ] Security risks are addressed.
[ ] The architecture matches the project size.
[ ] MVP scope is clearly separated from future scope.
[ ] Cost assumptions are realistic.
[ ] Third-party dependencies are identified.
[ ] Authentication and authorization are distinguished.
[ ] User flows are understandable.
[ ] Database design is justified.
[ ] API design is justified.
[ ] Testing strategy exists.
[ ] Deployment strategy exists.
[ ] Failure and edge cases are considered.
[ ] The final recommendation is actionable.

---

# FINAL OUTPUT FORMAT

Return the project document in this order:

1. Executive Summary
2. Project Overview
3. Problem Statement
4. Proposed Solution
5. Target Audience
6. User Roles & Permissions
7. Core Features
8. Functional Requirements
9. Non-Functional Requirements
10. Technical Architecture
11. Technology Stack
12. Database Design
13. API Design
14. Authentication & Authorization
15. Security Architecture
16. AI Architecture
17. User Experience
18. Admin System
19. Project Workflow
20. Development Phases
21. MVP Definition
22. Testing Strategy
23. Deployment Strategy
24. Cost Strategy
25. Scalability Plan
26. Analytics
27. Business Model
28. Risks
29. Future Roadmap
30. Acceptance Criteria
31. Open Questions & Assumptions
32. Final Recommendation

Use professional headings, concise paragraphs, tables where useful, numbered requirements, and implementation-oriented language.

The final document must be useful to both a business stakeholder and a software development team.