GOLD Standard Product V1 Blueprint — Deep Research, SVP, HLD, LLD, Features, UX, Architecture & Development Specification

# GOLD Standard Product V1 Blueprint — Deep Research, SVP, HLD, LLD, Features, UX, Architecture & Development Specification

## Objective

I want to build a production-ready **V1 software product** based on the domain name and business idea provided below.

Your job is to act as a combined:

* Product Manager
* Startup Product Strategist
* Business Analyst
* UX Architect
* UI/UX Designer
* SaaS Architect
* Solution Architect
* Senior Full-Stack Engineer
* Database Architect
* Security Engineer
* DevOps Engineer
* QA/Test Architect

Your task is to **deeply study the business idea, domain, target users, market, workflows, competing products, technical requirements, and operational requirements** and convert them into a complete, structured, development-ready specification.

The final result should be detailed enough that I can give it directly to an AI coding agent such as **Claude Code, ChatGPT/Codex, Cursor, or another engineering team** and start developing the product.

Do NOT jump directly into coding.

First understand the business.

Then define the product.

Then define the architecture.

Then define the implementation.

---

# 1. Product Input

## Domain Name

**Domain:** `[DOMAIN_NAME]`

Example:

`https://example.com/`

---

## Product / Business Idea

```text
[DESCRIBE YOUR IDEA HERE]

Explain:

- What the product should do
- Who should use it
- What problem it solves
- Whether it is B2B, B2C, SaaS, marketplace, internal tool, etc.
- Any special requirements
- Any initial features already in mind
```

---

# 2. Research Instructions

Before designing the system, deeply study the idea.

Where web research is available, research:

* Existing products solving similar problems
* Direct competitors
* Indirect competitors
* Common industry features
* Modern UX expectations
* User complaints about existing products
* Missing features in competitors
* Common pricing/business models
* Common onboarding models
* Common workflows
* Trust and security expectations
* Mobile requirements
* Regulatory considerations where relevant
* Internationalization requirements where relevant

Study at least several meaningful competitors when possible.

Do not blindly copy competitors.

Identify:

1. Industry-standard features
2. Features users expect by default
3. Features that differentiate products
4. Features that are unnecessary for V1
5. Opportunities to make this product simpler or better

Clearly separate:

* Research findings
* Recommendations
* Assumptions

If information is uncertain, say so.

---

# 3. Product Understanding

Start by explaining the product in simple language.

Include:

## Product Name

## Domain

## Product Category

## One-Line Product Description

## Elevator Pitch

## Problem Statement

## Proposed Solution

## Target Market

## Primary Users

## Secondary Users

## Who Should NOT Use This Product

## Core Value Proposition

## Unique Selling Proposition

## Main Business Model

Suggest appropriate monetization options such as:

* Subscription
* Freemium
* Transaction fee
* Commission
* Per-user pricing
* Per-location pricing
* Usage-based pricing
* Marketplace fees
* Advertising
* Enterprise licensing

Do not force monetization where it does not make sense.

---

# 4. Product Scope

Define three scopes separately.

## A. SVP — Smallest / Simple Viable Product

Identify the absolute smallest usable product.

The SVP must answer:

> What is the smallest complete workflow that delivers real value to the primary user?

Define:

* Core user
* Core problem
* Core workflow
* Minimum screens
* Minimum features
* Minimum database entities
* Minimum administration
* Minimum authentication
* Minimum notifications
* Minimum reporting

Do NOT turn the SVP into a mini-enterprise product.

---

## B. MVP

Define what should be added after the SVP to validate the broader product/business.

Separate:

* Must Have
* Should Have
* Could Have
* Not Required

---

## C. V1

Define the recommended production V1.

V1 should be:

* Stable
* Secure
* Understandable
* Maintainable
* Useful enough for real customers
* Deployable to production
* Suitable for collecting real customer feedback

Avoid unnecessary enterprise complexity.

---

# 5. Feature Classification

Create a master feature matrix.

Use categories:

| Feature | Description | User | SVP | MVP | V1 | Priority | Complexity | Dependency |
| ------- | ----------- | ---- | --- | --- | -- | -------- | ---------- | ---------- |

Priorities:

* P0 — Critical
* P1 — Important
* P2 — Useful
* P3 — Future

Also classify every feature as:

* Core
* Admin
* Security
* Reporting
* UX
* Integration
* Operational
* Growth
* Future

---

# 6. Complete Feature Specification

For every V1 feature provide:

## Feature Name

## Purpose

## Why It Exists

## Users

## Preconditions

## User Actions

## System Actions

## Business Rules

## Validation Rules

## Permissions

## Data Required

## Success State

## Error States

## Edge Cases

## Notifications

## Audit Requirements

## Acceptance Criteria

Do this for every major feature.

Do not merely give a feature-name list.

---

# 7. Types of Users

Identify every required user type.

Examples may include:

* Visitor
* Registered User
* Customer
* Employee
* Manager
* Organization Admin
* Location Admin
* Super Admin
* Support Staff
* Finance Staff
* Auditor

Use only roles appropriate to this product.

Create:

| Role | Purpose | Main Permissions | Restrictions |
| ---- | ------- | ---------------- | ------------ |

---

# 8. RBAC — Roles & Permissions

Design a detailed Role-Based Access Control model.

For every important resource specify permissions such as:

* View
* Create
* Edit
* Delete
* Approve
* Reject
* Export
* Configure
* Assign
* Manage

Create a permission matrix.

Example:

| Resource / Action | User | Manager | Org Admin | Super Admin |
| ----------------- | ---: | ------: | --------: | ----------: |

Avoid unnecessary role complexity.

---

# 9. User Journeys

Create complete user journeys for every important user type.

For each journey provide:

## Goal

## Entry Point

## Steps

## Decisions

## Success Outcome

## Failure Conditions

## Recovery Flow

## Notifications

## Permissions

Examples:

* Registration
* Login
* Forgot password
* Initial onboarding
* Creating first record
* Main transaction
* Editing
* Cancellation
* Approval
* Search
* Reporting
* Account settings
* Logout

Use Mermaid diagrams where they improve clarity.

---

# 10. Workflow Design

Document important system workflows.

For every workflow include:

```text
Trigger
↓
Validation
↓
Business Logic
↓
Database Action
↓
Notification
↓
Audit Log
↓
Final State
```

Create Mermaid flowcharts for important workflows.

Include:

* Happy path
* Failure path
* Retry path
* Cancellation path
* Permission-denied path

---

# 11. Screen / Page Inventory

Create a complete inventory of pages/screens.

Group them under:

## Public Website

## Authentication

## User Application

## Dashboard

## Administration

## Account Settings

## Error/System Pages

For every screen provide:

| Screen | Route | User | Purpose | Major Components | Main Actions |
| ------ | ----- | ---- | ------- | ---------------- | ------------ |

---

# 12. UI/UX Specification

For each important screen explain:

* Layout
* Header
* Sidebar
* Navigation
* Cards
* Tables
* Forms
* Filters
* Search
* Pagination
* Empty states
* Loading states
* Error states
* Confirmation dialogs
* Success messages
* Mobile behavior

Follow modern SaaS UX principles.

Prefer simple and obvious UX over visually complicated UX.

---

# 13. Admin Panel

Design the complete administration system.

Evaluate whether we need:

## Platform Super Admin

Possible capabilities:

* Dashboard
* Users
* Organizations
* Plans
* Subscriptions
* Payments
* Support
* Reports
* System configuration
* Email templates
* Audit logs
* Feature controls

## Organization Admin

Possible capabilities:

* Organization profile
* Employees/users
* Roles
* Settings
* Locations
* Working rules
* Billing
* Reports
* Integrations

Only include capabilities relevant to the product.

For each admin option explain:

* Purpose
* Who can use it
* Editable fields
* Validation
* Security impact

---

# 14. Dashboard Design

Define dashboards for every relevant role.

For each dashboard specify:

* KPIs
* Summary cards
* Charts
* Tables
* Alerts
* Pending actions
* Recent activity
* Quick actions

Do not add charts just because charts are available.

Every chart or KPI should answer a useful business question.

---

# 15. Search, Filtering & Sorting

Define:

* Searchable fields
* Filters
* Sorting
* Pagination
* Date ranges
* Saved filters if necessary
* Export options

Explain expected behavior for zero results and invalid searches.

---

# 16. Notifications

Determine whether the product needs:

* In-app notifications
* Email notifications
* SMS
* Push notifications

For V1, keep external services minimal.

Create a notification matrix:

| Event | Recipient | Channel | Required? | Template |
| ----- | --------- | ------- | --------- | -------- |

---

# 17. HLD — High-Level Design

Create the High-Level Design.

Include:

## System Architecture

Provide a Mermaid architecture diagram.

Cover:

```text
Browser
↓
Next.js Application
↓
Application / Business Logic
↓
Prisma ORM
↓
PostgreSQL

Additional components where necessary:
Authentication
Local file storage
PDF generation
Email provider
Nginx
PM2
Logging
Backups
```

Explain:

* Component responsibilities
* Request flow
* Authentication flow
* File flow
* Reporting flow
* Deployment flow

---

# 18. Technology Stack

Use the following stack as the **default architecture** unless there is a strong technical reason to change something.

| Area               | Final Choice                                           |
| ------------------ | ------------------------------------------------------ |
| Frontend           | **Next.js + TypeScript**                               |
| Backend            | **Next.js Server Actions / API Routes**                |
| UI                 | **Tailwind CSS + shadcn/ui**                           |
| Database           | **PostgreSQL**                                         |
| ORM                | **Prisma**                                             |
| Authentication     | **Auth.js / NextAuth with Google Login + Email Login** |
| File Storage       | **Local file storage**                                 |
| Report Generation  | **HTML to PDF**                                        |
| Charts / Dashboard | **Recharts**                                           |
| Hosting            | **Linux VPS — Single Server**                          |
| Web Server         | **Nginx**                                              |
| Process Manager    | **PM2**                                                |
| Queue              | **Not required in Phase 1**                            |
| Cache / Redis      | **Not required in Phase 1**                            |
| AI                 | **Not required unless genuinely needed**               |

### Architecture Principle

Keep V1 architecture deliberately simple.

Do NOT introduce without a strong reason:

* Kubernetes
* Microservices
* Kafka
* Redis
* RabbitMQ
* Elasticsearch
* Multiple databases
* Service mesh
* Complex event-driven architecture
* Serverless fragmentation

Prefer:

> Modular Monolith + PostgreSQL + Next.js

The system should still be structured so components can be extracted later if scale requires it.

---

# 19. LLD — Low-Level Design

Create detailed Low-Level Design for the major modules.

For every module specify:

## Module Name

## Responsibility

## Components

## Server Actions

## API Routes

## Services

## Repositories if needed

## Prisma Models

## Validation

## Authorization

## Error Handling

## Logging

## Dependencies

## Tests

Suggested modular organization:

```text
src/
├── app/
├── components/
├── features/
├── lib/
├── services/
├── actions/
├── validations/
├── types/
├── hooks/
├── config/
└── utils/
```

Improve this structure if necessary.

---

# 20. Database Architecture

Design the complete PostgreSQL data model.

For every entity provide:

* Table name
* Purpose
* Fields
* Data types
* Nullable/non-nullable
* Primary key
* Foreign keys
* Unique constraints
* Indexes
* Defaults
* Relationships
* Delete behavior
* Audit fields

Use:

```text
createdAt
updatedAt
```

where appropriate.

Add:

```text
createdBy
updatedBy
deletedAt
```

only where justified.

---

# 21. Entity Relationship Diagram

Create a Mermaid ER diagram.

Example structure:

```mermaid
erDiagram
    USER ||--o{ ORGANIZATION_MEMBER : belongs
```

The diagram must match the proposed database.

---

# 22. Prisma Schema Design

Provide a recommended Prisma model structure.

Do not necessarily generate the entire production schema if extremely large, but provide enough that implementation can begin directly.

Explain important:

* Relations
* Indexes
* Enums
* Unique keys
* Cascading behavior

---

# 23. API / Server Action Design

Identify every important backend operation.

Create:

| Operation | Type | Route / Action | Auth | Role | Input | Output |
| --------- | ---- | -------------- | ---- | ---- | ----- | ------ |

For each important operation define:

* Input schema
* Validation
* Authorization
* Business logic
* Database operation
* Response
* Error conditions

Prefer Server Actions for application-internal mutations where appropriate.

Use API Routes when there is a genuine API requirement such as:

* External integrations
* Webhooks
* Public endpoints
* Downloads
* Third-party callbacks

---

# 24. Validation Rules

Create a centralized validation strategy.

Prefer:

* Zod
* Shared TypeScript types
* Server-side validation as authoritative validation
* Client-side validation for UX

For every important form describe:

* Required fields
* Format rules
* Min/max
* Date constraints
* Duplicate constraints
* Business-rule constraints
* Cross-field validation

---

# 25. Authentication

Design:

## Google Login

## Email Login

## Registration

## Email Verification

## Password Reset

## Session Handling

## Logout

## Account Disable

## Account Delete

Explain:

* Session strategy
* Security
* Redirects
* First-login onboarding
* Unauthorized behavior

---

# 26. Authorization

Authentication and authorization must be treated separately.

Define:

```text
Authentication:
Who are you?

Authorization:
What are you allowed to do?
```

All sensitive authorization must happen server-side.

Never rely purely on hidden UI elements for permission enforcement.

---

# 27. Security Requirements

Include practical V1 security.

Cover:

* Password security
* Session security
* CSRF
* XSS
* SQL injection
* Input validation
* File upload validation
* MIME validation
* Upload size restrictions
* Path traversal
* Authentication abuse
* Login rate limiting
* Authorization bypass
* IDOR protection
* Secure cookies
* Secrets management
* Environment variables
* HTTPS
* Security headers
* Audit logs
* Error information leakage

Apply OWASP principles without unnecessarily overengineering the product.

---

# 28. File Storage

Since V1 uses local file storage, define:

```text
/data/uploads/
```

or an equivalent location outside the public application directory.

Define:

* Directory structure
* Naming strategy
* UUID filenames
* Original filename handling
* Allowed file types
* Maximum size
* Permission checking
* Download authorization
* Backup behavior
* Delete behavior

Ensure the architecture makes later migration to S3-compatible object storage straightforward.

---

# 29. PDF / Report Generation

If reports are required, define:

```text
Application Data
→ HTML Template
→ PDF Renderer
→ PDF
```

Describe:

* Templates
* Branding
* Headers
* Footers
* Page numbers
* Tables
* Charts
* Download permissions
* Storage vs on-demand generation

Recommend appropriate Node.js-compatible tooling.

---

# 30. Audit Logging

Determine which events need audit records.

Examples:

* Login
* Failed login
* User creation
* Role changes
* Configuration changes
* Record deletion
* Approval
* Cancellation
* Security-sensitive actions

Suggested structure:

```text
Actor
Action
Resource
Resource ID
Timestamp
Old Value
New Value
IP
User Agent
```

Do not log secrets or passwords.

---

# 31. Error Handling

Design a standardized error model.

Separate:

* Validation error
* Authentication error
* Authorization error
* Not found
* Conflict
* Business rule violation
* Internal error

Define user-facing versus server-side error information.

---

# 32. Logging

Define useful production logging.

Include:

* HTTP failures
* Authentication events
* Application errors
* Database failures
* Background/report failures
* Security events

Avoid logging:

* Passwords
* Tokens
* OAuth secrets
* Sensitive personal data unnecessarily

---

# 33. Backup & Recovery

Because this is a single VPS deployment, define a practical backup strategy.

Include:

## PostgreSQL

* Automated database backup
* Retention
* Off-server backup

## Uploaded Files

* Scheduled file backup
* Off-server copy

## Application

* Git repository
* Environment variable backup procedure

Define a basic restore procedure.

---

# 34. Deployment Architecture

Target:

```text
Internet
   ↓
DNS
   ↓
Nginx
   ↓
Next.js Application
   ↓
PM2
   ↓
PostgreSQL
```

Describe:

* Linux user
* Folder layout
* Nginx reverse proxy
* HTTPS
* PM2
* PostgreSQL
* Environment variables
* Logs
* Upload directory
* Backup directory

---

# 35. Suggested VPS Folder Structure

Recommend something similar to:

```text
/opt/product/
├── app/
├── releases/
├── shared/
│   ├── uploads/
│   ├── logs/
│   └── .env
└── backups/
```

Explain ownership and permissions.

---

# 36. Deployment Process

Define a simple deployment workflow:

```text
Developer
↓
Git Repository
↓
Pull/build on server or CI/CD
↓
npm install
↓
Prisma migration
↓
Next.js build
↓
PM2 reload
↓
Health check
```

Include rollback strategy.

---

# 37. Environment Strategy

Define:

```text
Development
Staging
Production
```

Explain which environments are actually necessary for early V1.

Define `.env` requirements.

Example:

```text
DATABASE_URL
AUTH_SECRET
GOOGLE_CLIENT_ID
GOOGLE_CLIENT_SECRET
APP_URL
UPLOAD_DIR
```

Add other required variables.

---

# 38. Application Configuration

Identify values that should NOT be hard-coded.

Examples:

* Product name
* Time zone
* Locale
* Currency
* Date format
* File limits
* Email sender
* Pagination size
* Business rules
* Feature switches

Decide whether configuration belongs in:

* Environment variables
* Database settings
* Constants

---

# 39. Internationalization

Determine whether V1 needs:

* Multiple languages
* Multiple currencies
* Multiple time zones
* Local date/time formatting
* Local phone formats
* International addresses

Even if V1 launches in one country, avoid database designs that make international expansion unnecessarily difficult.

---

# 40. Responsive Design

Design for:

* Desktop
* Tablet
* Mobile browser

Identify workflows that need special mobile UX.

Do NOT build separate native mobile apps unless required.

The web application should be structured so that later it could support:

* PWA
* Mobile wrapper
* Native application API

---

# 41. Accessibility

Include basic accessibility requirements:

* Keyboard navigation
* Form labels
* Focus states
* Color contrast
* ARIA where appropriate
* Error announcements
* Semantic HTML

Target practical WCAG-aligned behavior.

---

# 42. Performance

Define realistic V1 performance expectations.

Consider:

* Database indexes
* Pagination
* Avoiding N+1 queries
* Server-side rendering
* Image optimization
* Lazy loading
* Query optimization
* Caching only where justified

Do NOT introduce Redis simply to claim better performance.

---

# 43. SEO

If the product contains public-facing pages, define:

* Metadata
* Canonical URLs
* Sitemap
* robots.txt
* Open Graph
* Structured data
* Public profile indexing
* Dynamic metadata
* Slugs

Separate private application pages from indexable pages.

---

# 44. Analytics

Recommend lightweight analytics if useful.

Track meaningful events such as:

```text
Signup
Registration completed
First core action
Transaction completed
Cancellation
Conversion
Subscription
```

Avoid excessive tracking in V1.

---

# 45. Testing Strategy

Create a complete but practical V1 testing strategy.

Include:

## Unit Tests

## Integration Tests

## API Tests

## Authentication Tests

## Authorization Tests

## Database Tests

## UI Tests

## End-to-End Tests

## Security Tests

## Regression Tests

For every important feature create test scenarios covering:

```text
Positive
Negative
Boundary
Validation
Authorization
Security
Error handling
```

---

# 46. GOLD Acceptance Criteria

Define acceptance criteria for every P0 and P1 feature.

Use Given / When / Then where appropriate.

Example:

```text
Given an authenticated organization administrator
When they invite a valid email address
Then an invitation must be created
And the invitee must receive the appropriate notification
And the event must appear in the audit log.
```

---

# 47. Edge Cases

Explicitly identify edge cases.

Examples:

* Duplicate submission
* Refresh during transaction
* Two admins editing simultaneously
* Deleted referenced record
* Expired session
* Disabled account
* Invalid role
* Empty dataset
* Very long input
* Invalid uploaded file
* Network failure
* Database failure
* Browser back button
* Multiple tabs
* Time-zone boundaries
* Daylight-saving boundaries if relevant

---

# 48. Business Rules

Create one consolidated section containing ALL important business rules.

Number them:

```text
BR-001
BR-002
BR-003
```

Each business rule should be testable.

---

# 49. Data Retention & Deletion

Define:

* User deletion
* Organization deletion
* Soft delete vs hard delete
* Audit retention
* Uploaded-file deletion
* Orphan cleanup
* Account termination

---

# 50. Future Scalability

Explain how the V1 can later migrate from:

```text
Single VPS
```

to something larger.

Possible future evolution:

```text
Object Storage
Managed PostgreSQL
Redis
Background Workers
CDN
Load Balancer
Multiple App Nodes
Containerization
```

Do NOT implement those now unless necessary.

The objective is:

> Simple today, evolvable tomorrow.

---

# 51. What NOT to Build in V1

Create an explicit:

# NOT IN V1

section.

For each excluded feature explain briefly why it should wait.

This section is extremely important to prevent scope creep.

---

# 52. Recommended Development Order

Produce a phased engineering plan.

Example:

## Phase 0 — Foundation

* Repository
* Next.js
* TypeScript
* Tailwind
* shadcn/ui
* Prisma
* PostgreSQL
* Auth
* Base layout

## Phase 1 — Core Data Model

## Phase 2 — Core Workflow

## Phase 3 — Administration

## Phase 4 — Reporting

## Phase 5 — Hardening

## Phase 6 — Production Deployment

Customize this according to the actual product.

---

# 53. Development Tasks

Break implementation into small development tasks suitable for Claude Code/Codex.

Each task should contain:

```text
Task ID
Task Name
Purpose
Dependencies
Files/Modules likely affected
Implementation Notes
Acceptance Criteria
Tests
```

Tasks should be small enough to implement and review independently.

Example:

```text
DEV-001
DEV-002
DEV-003
```

---

# 54. Dependency Graph

Explain which components depend on others.

Example:

```text
Authentication
   ↓
User Management
   ↓
Organization
   ↓
Core Feature
   ↓
Reports
```

Use Mermaid where useful.

---

# 55. Repository Structure

Recommend the final repository structure.

Example:

```text
/
├── src/
│   ├── app/
│   ├── components/
│   ├── features/
│   ├── lib/
│   ├── actions/
│   ├── services/
│   ├── validations/
│   ├── types/
│   └── config/
│
├── prisma/
│   ├── schema.prisma
│   ├── migrations/
│   └── seed.ts
│
├── public/
│
├── tests/
│   ├── unit/
│   ├── integration/
│   └── e2e/
│
├── docs/
│
├── scripts/
│
├── package.json
├── next.config.ts
├── tsconfig.json
└── README.md
```

Modify where necessary.

---

# 56. Documentation Files to Create

At the end, provide the recommended `/docs` structure.

I want documentation such as:

```text
docs/
├── 00-product-overview.md
├── 01-research.md
├── 02-svp.md
├── 03-v1-scope.md
├── 04-features.md
├── 05-users-and-roles.md
├── 06-user-flows.md
├── 07-business-rules.md
├── 08-hld.md
├── 09-lld.md
├── 10-database.md
├── 11-api.md
├── 12-ui-ux.md
├── 13-security.md
├── 14-testing.md
├── 15-deployment.md
├── 16-development-plan.md
└── 17-future-roadmap.md
```

Recommend additional files if useful.

---

# 57. CLAUDE.md

Create a recommended `CLAUDE.md` for the repository.

It should tell an AI coding agent:

* Product purpose
* Architecture
* Technology choices
* Coding conventions
* Folder structure
* Authentication rules
* Authorization rules
* Database rules
* UI conventions
* Validation standards
* Security rules
* Testing expectations
* Commands
* Things it must never do
* V1 scope boundaries

The objective is to keep future AI-generated code consistent.

---

# 58. Coding Standards

Recommend standards such as:

* TypeScript strict mode
* Avoid `any`
* Prefer server components where appropriate
* Client components only where required
* Zod validation
* Prisma database access
* Centralized authorization
* Reusable UI components
* No duplicated business logic
* No secrets in source code
* Consistent error handling
* Consistent naming conventions

---

# 59. Definition of Done

Create a universal Definition of Done.

A feature is NOT complete just because the UI exists.

A feature should normally require:

* UI completed
* Backend completed
* Database completed
* Validation completed
* Authorization completed
* Error handling completed
* Loading/empty states completed
* Logging where relevant
* Audit logging where relevant
* Tests completed
* Mobile UX checked
* Security checked
* Acceptance criteria passed

---

# 60. Launch Readiness Checklist

Create a final V1 production checklist covering:

## Product

## UX

## Authentication

## Authorization

## Security

## Database

## Backups

## Email

## Domain

## DNS

## HTTPS

## Nginx

## PM2

## Monitoring

## Logging

## Error Handling

## SEO

## Privacy

## Terms

## Testing

## Performance

## Deployment

## Rollback

---

# 61. Final Product Blueprint Summary

At the end provide one concise summary containing:

### Product

### Primary User

### Core Problem

### SVP

### V1

### Main Workflow

### Main Roles

### Main Features

### Architecture

### Database

### Authentication

### Hosting

### Biggest Risks

### V1 Exclusions

### Development Sequence

---

# 62. Critical Instructions

Follow these rules throughout the analysis.

### Rule 1 — Research Before Architecture

Do not design blindly.

Understand the product and industry first.

### Rule 2 — Do Not Overengineer

This is a V1.

Use the simplest architecture capable of securely supporting real customers.

### Rule 3 — Think Production, Not Demo

The system must account for:

* Security
* Validation
* Permissions
* Backups
* Error handling
* Auditability
* Deployment
* Recovery

### Rule 4 — Challenge My Idea

If my proposed feature, technology, workflow, or assumption is poor, explain why and recommend something better.

Do not agree with everything automatically.

### Rule 5 — Avoid Feature Bloat

Every feature should have a reason to exist.

### Rule 6 — Separate SVP, MVP, V1 and Future

Never mix them.

### Rule 7 — User Experience Comes First

Minimize:

* Clicks
* Confusion
* Unnecessary fields
* Unnecessary setup
* Repeated work

### Rule 8 — Design for Real Failure Cases

Don't describe only happy paths.

### Rule 9 — Make Decisions

Do not give endless alternatives.

When several approaches exist:

1. Explain the options briefly.
2. Select the recommended approach.
3. Explain why.

### Rule 10 — Development-Ready Output

The final result should be specific enough that another AI coding agent or software engineer can implement the product without having to redesign the product from scratch.

---

# Final Instruction

Study this product as though **you are responsible for launching it successfully yourself**.

Think deeply about:

> Business → Users → Problems → SVP → V1 → Features → UX → Workflows → Business Rules → Data → HLD → LLD → Security → Testing → Deployment → Operations → Future Scale

Do not optimize for the longest possible response.

Optimize for:

> **Completeness + Correctness + Simplicity + Maintainability + Real-World Usability**

The ultimate goal is to produce a **GOLD-standard V1 product blueprint that can immediately become the source of truth for development.**