# Genesis System Revenue Map
*Report Generated: 2026-02-15*

## 1. Executive Summary

The Genesis system's revenue infrastructure is in a **planning and pre-implementation stage**. While extensive strategic documentation, detailed plans, and even code snippets exist across the key areas (payments, CRM, email outreach), there is **no single, fully functional, end-to-end pipeline to charge customers**.

The most advanced component is the GoHighLevel (GHL) integration, which has a partially functional script for lead importation. The payment processing component (Stripe) is well-defined in a planning document with code, but it is not integrated into a live application and has a critical security flaw in its current state. Lead lists are well-curated but require manual effort to enrich with contact data before outreach can be automated.

Overall, the strategy is clear, but significant engineering work is required to connect the components, secure them, and build the necessary user-facing interfaces.

---

## 2. Stripe Integration (Payment Processing)

- **What Exists:**
    - **Extensive Planning Documents:** Numerous markdown files (`REVENUE LAUNCH CONTEXT/`, `Sunaiva/ai-memory/`) detail a comprehensive Stripe integration strategy, including 3-tier pricing, setup fees, and webhook-driven automation.
    - **Code Blueprint:** The `Sunaiva/ai-memory/SUNAIVA_EVOLUTION_PLAN.md` file contains a substantial Python code blueprint for a FastAPI backend. This code outlines creating Stripe Checkout sessions, customer portals for subscription management, and handling key webhooks (`checkout.session.completed`, `customer.subscription.deleted`).
    - **CLI Commands:** The same planning document includes Stripe CLI commands for creating products and prices, aligning with a planned 3-tier subscription model.

- **Functionality Status: NOT FUNCTIONAL**
    - The Python code is embedded within a markdown file, not in a runnable `.py` application file.
    - It has a **critical security vulnerability** noted in `Sunaiva/ai-memory/BACKEND_AUDIT.md`: Stripe webhook signature verification is disabled if the webhook secret isn't set, which would allow subscription fraud.
    - Database interactions are commented out and require a live database.
    - It depends on environment variables for API keys and Price IDs which are not configured.

- **Missing Pieces to Charge Customers:**
    1.  **Code Extraction & Integration:** Move the Python code from the markdown file into a live, secure FastAPI (or similar) application.
    2.  **Fix Security Flaw:** Implement mandatory Stripe webhook signature verification.
    3.  **User Authentication:** A full user registration/login system is needed to link customers to Stripe Customer IDs.
    4.  **Frontend UI:** A user interface for selecting plans and initiating the checkout process.
    5.  **Configuration:** Set up and securely store live Stripe API keys, webhook secrets, and price IDs.

---

## 3. Payment Flows, Subscriptions, Pricing & UI

- **What Exists:**
    - **Defined Flow:** The planned flow is: **User clicks "Subscribe" -> Redirect to Stripe Checkout -> Successful payment triggers Stripe webhook -> Webhook call hits application endpoint -> Application updates user's subscription status in the database and triggers GHL onboarding workflow.** This is a standard and robust model.
    - **Pricing Strategy:** A 3-tier model of **$499 / $850 / $1,450** is defined as "AUTHORITATIVE" in `REVENUE_LAUNCH_EXECUTIVE_SUMMARY.md`. The `Sunaiva` project documents a different set of tiers ($47/$97/$197 per month), indicating a need for strategic consolidation.
    - **Subscription Logic:** The `Sunaiva/ai-memory/server/billing.py` file contains Python functions to handle subscription lifecycle events like creation, updates, and cancellations based on Stripe webhooks.
    - **UI Mockup:** A static HTML pricing page exists in `Sunaiva/ai-memory/index.html`, providing a basic visual layout.

- **Functionality Status: NOT FUNCTIONAL**
    - The flow is only a plan. No code connects the frontend UI to the backend, or the backend to GHL.
    - The pricing strategy is not configured in any live application.
    - The auth system to link users to subscriptions is only a placeholder (`require_auth`).

- **Missing Pieces to Charge Customers:**
    1.  **User Authentication System:** To manage user accounts and link them to subscriptions.
    2.  **Dynamic Frontend:** A React/Vue or similar frontend to handle plan selection and user state.
    3.  **Backend Implementation:** The backend code needs to be completed, secured, and deployed.
    4.  **Pricing Consolidation:** A final decision on the pricing strategy must be made and configured in the application's environment.

---

## 4. Instantly.ai (Email Outreach)

- **What Exists:**
    - **Python Skill Definition:** A file `skills/instantly_skill.py` exists that defines functions for interacting with the Instantly.ai API (e.g., `list_campaigns`, `add_leads`).
    - **Strategic Documents:** Instantly.ai is a core part of the marketing strategy, with documents confirming a subscription has been purchased and outlining detailed setup procedures (`RECEPTIONISTAI/marketing/INSTANTLY_OPTIMAL_SETUP.md`).

- **Functionality Status: NOT FUNCTIONAL**
    - The `instantly_skill.py` uses a **deprecated v1 API**. `RESEARCH_REPORTS/INSTANTLY_AI_MASTERY_REPORT.md` explicitly notes the v2 API is at `developer.instantly.ai`.
    - No API key is configured in the system.
    - The planned `core/instantly_client.py` has not been built.

- **Missing Pieces to Charge Customers:**
    1.  **API V2 Client:** The skill/client needs to be rewritten to use the current Instantly.ai v2 API.
    2.  **API Key Integration:** A live API key needs to be stored as a secure environment variable.
    3.  **Automation Workflow:** An automated process needs to be built to take leads from the CSVs/GHL, enrich them with contact info, and use the API client to add them to Instantly.ai campaigns.

---

## 5. GoHighLevel (GHL) Integration (CRM)

- **What Exists:**
    - **Dedicated MCP Server:** A GHL MCP server exists at `mcp-servers/ghl`.
    - **Python Bridge/Client:** Scripts exist to connect the Python environment to the Node.js MCP server.
    - **Lead Import Script:** `tools/ghl_round_trip_sync.py` is a functional script for importing leads from a CSV file into GHL and tagging them. It includes a test API key.
    - **API Endpoint References:** Planning documents contain direct GHL REST API endpoints for actions like updating contacts and subscribing them to workflows.

- **Functionality Status: PARTIALLY FUNCTIONAL**
    - The lead import script is the most functional piece of the entire revenue stack, capable of populating the CRM with the identified leads.
    - The broader integration for automated workflows based on payments or other triggers is not implemented.

- **Missing Pieces to Charge Customers:**
    1.  **Production API Key:** The test API key needs to be replaced with a production key in a secure configuration.
    2.  **End-to-End Workflow Implementation:** The code or GHL workflow configuration to connect payment events (from the Stripe webhook) to specific actions (like triggering an onboarding email sequence) needs to be built.

---

## 6. Lead Lists

- **What Exists:**
    - A `data/LEADS/` directory contains structured and segmented lead lists.
    - `GOLD_LIST_AI_AUTOMATION_329.csv` is a high-quality list of 329 qualified social media influencers for the Sunaiva project. The data includes follower counts, engagement rates, niches, and a priority score.
    - Other directories indicate lead lists for "Tradie" focused projects.

- **Functionality Status: FUNCTIONAL (as a data source)**
    - The lead lists are well-structured and ready for the next step of the outreach process.

- **Missing Pieces to Charge Customers:**
    1.  **Contact Information:** The CSV file shows that critical contact information (Email, Website) is marked "TBD". This data needs to be found and enriched, which is currently a manual research task.
    2.  **Enrichment & Outreach Automation:** A workflow is needed to automate the process of finding contact details for these leads and then feeding them into the (yet-to-be-built) Instantly.ai outreach system.

---

## 7. Path to Charging Customers (Action Plan)

To create a functional revenue pipeline, the following key engineering tasks must be completed:

1.  **Build & Secure the Payment Backend:** Extract the Stripe code into a dedicated, secure web application. Fix the webhook vulnerability and implement a full user authentication system.
2.  **Develop the Frontend UI:** Create a user-facing interface for users to sign up, log in, select a subscription plan, and complete payment via Stripe Checkout.
3.  **Update the Email Outreach Client:** Rebuild the Instantly.ai client to use the current v2 API and configure it with a production API key.
4.  **Connect the Pipeline:**
    -   Create the webhook endpoint that listens for successful Stripe payments.
    -   Implement the logic in this endpoint to:
        -   Update the user's subscription status in the local database.
        -   Make an API call to GHL to tag the contact as "active" and trigger the onboarding workflow.
5.  **Automate Lead Management:**
    -   Build a process to enrich the existing lead lists with contact information.
    -   Connect the GHL lead import script to the Instantly.ai client to create a seamless "lead to outreach" pipeline.
