MVP Development

You are a full-stack senior engineer.

I want to first have a high-level conversation with you to understand the idea that I would like to build, and then generate all the required documentation:

This is my idea:

[idea]

Before we generate the below documentation, let's have a high-level conversation to understand the idea and ensure we're on the same page.

Ask me questions to help you understand the idea better. Ask about edge cases, pricing models, APIs I might use, websites I know similar to what I'm building, etc. etc.

Get as much context as possible from me about the idea.

Initially use my idea to first create a markdown file in the docs folder called 'idea.md' that captures the high-level idea and business model.

Everytime you ask me a clarifying question, ask me if I am satisfied with the current state of the 'idea.md' file. Once I reply with a 'yes' (or similar), then you can help me generate the following detailed documentation files based on the 'idea.md' file:

1) A high level product requirements doc (PRD) detailing the core feature/s of the MVP only, following this format:
  - Introduction: Problem statement and product vision (what is the painpoint we are solving)
  - Objectives & Goals: Core purpose and ideal outcomes
  - Target Users & Roles: User types and their actions
  - Core Features for MVP: Must-have functionality (Just 1 or 2 core features that users can't live without)
  - Future Scope: Features for later phases
  - User Journey: Step-by-step flows for each role
  - Tech Stack: Main Stack + 3rd Party libraries/providers/APIs to be used
2) A technical design doc (TDD) explaining what libraries and providers we should use to implement all the features (any 3rd party libraries if needed)
3) An updated database schema on top of my initial schema:
  model user {
    id                Int      @id @default(autoincrement())
    created_time      DateTime @default(now())
    email             String   @unique
    first_name        String?
    last_name         String?
    gender            String?
    profile_image_url String?
    user_id           String   @unique
    subscription      String?
  }

  model payments {
    id               Int      @id @default(autoincrement())
    created_time     DateTime @default(now())
    stripe_id        String
    email            String
    amount           String
    payment_time     String
    payment_date     String
    currency         String
    user_id          String
    customer_details String
    payment_intent   String
  }

  model subscriptions {
    id                        Int      @id @default(autoincrement())
    created_time              DateTime @default(now())
    subscription_id           String
    stripe_user_id            String
    status                    String
    start_date                String
    end_date                  String?
    plan_id                   String
    default_payment_method_id String?
    email                     String
    user_id                   String
  }

  model subscriptions_plans {
    id           Int      @id @default(autoincrement())
    created_time DateTime @default(now())
    plan_id      String
    name         String
    description  String
    amount       String
    currency     String
    interval     String
  }

  model invoices {
    id              Int      @id @default(autoincrement())
    created_time    DateTime @default(now())
    invoice_id      String
    subscription_id String
    amount_paid     String
    amount_due      String?
    currency        String
    status          String
    email           String
    user_id         String?
  }

  Create any connections to these initial tables as needed.

  Advise based on the recommended pricing model whether I would need both a subscription pricing model or a one-time payment model.

  Use this as a reference for the pricing model decision:

  1. **Recurring Subscriptions**
   - Use when you provide ongoing value
   - Examples:
     - SaaS tools used regularly
     - Monitoring services
     - Continuous access platforms
   - Benefits:
     - Predictable revenue
     - Higher customer lifetime value
     - Easier to scale

  2. **One-Time Payments**
    - Use when value is delivered once
    - Examples:
      - Digital downloads
      - One-off transformations
      - Limited-time access
    - Benefits:
      - Simpler to manage
      - No recurring obligations
      - Clear value proposition

  3. **Hybrid Models**
    - Combine both payment types
    - Examples:
      - Course platform with setup fee + monthly access
      - Software with one-time purchase + optional subscription support
    - Benefits:
      - Maximizes revenue opportunities
      - Caters to different user preferences
      - Provides flexibility in pricing strategy

  If, for example, you think we should use a one-time payment model, then remove the subscriptions and subscription plans tables and remove the subscription_id from the invoices table.

  Also, based on my idea, can you generate the entire landing page copy in a markdown file in the docs folder called 'landing-page-copy.md'. See the attached template landing page layout image for reference.

  Make sure to include a compelling value proposition, unique selling points, and a clear call to action. Make it crystal clear what the main benefit of the product is. It should be so simple that a 5 year old could understand it.

  The FAQs should absolutely be the most common questions that you think people would ask about the product. 5-8 FAQs are perfect (including a link to the refund policy).

  4) A list of the most common user flows

  5) UI/UX Design of the main app/dashboard:
  - Create a minimal UI design focusing on core functionality
  - Explain the main user interactions and flows
  - Highlight key UI components and their purpose
  - Document accessibility considerations
  - Define responsive design approach

  6) System Architecture (in Mermaid.js):
  Generate a high-level system design diagram showing:
  - Key components and their relationships
  - Data flow between services
  - External API integrations
  - Infrastructure layout

  Add these docs to a 'docs' folder at the root of the codebase.

Update @prisma.schema with the database schema changes we need to allow for my idea's features.

See @docs/database-schema.md