Cursor Rules Template: Sales Pipeline SaaS with Lead Scoring, Email Tracking, and AI Dashboards

Overview

This Cursor Rules Template provides a ready-to-paste configuration for Cursor AI that targets building a multi-tenant sales pipeline management SaaS. It covers lead scoring, email tracking, deal stages, dashboards, and AI-generated summaries, focusing on a Node.js and PostgreSQL stack with strong security and data governance for a SaaS product.

Direct answer: paste the copyable .cursorrules block below into your project root to enforce architecture, security, and development patterns for a Cursor AI assisted Salesforce-like pipeline system.

When to Use These Cursor Rules

When implementing a SaaS CRM with multi-tenant data separation and auditability
When integrating email tracking and lead scoring into the pipeline workflow
When defining deal stages and AI-assisted summaries for dashboards
When enforcing consistent project structure, security, and testing in a Node.js + PostgreSQL stack
When you want an auditable, repeatable set of engineering rules enforced by Cursor AI

Copyable .cursorrules Configuration


# Cursor Rules Template - Sales Pipeline SaaS
Framework Role & Context:
- Role: Backend Engineer for a multi-tenant SaaS CRM built on Node.js and PostgreSQL.
- Context: Cursor AI acts as a coding assistant to implement lead scoring, email tracking, deal stages, dashboards, and AI summaries with strict RBAC, data isolation, and auditable changes.

Code Style and Style Guides:
- Language: TypeScript
- Style Guide: ESLint + Prettier; Airbnb rules
- Naming: kebab-case filenames, PascalCase exports
- Tests: unit tests with Jest, integration tests with SuperTest
- Commit messages: conventional

Architecture & Directory Rules:
- Repo structure enforced: apps/api, services, dashboards, libs
- Key directories:
  apps/api/src/
  services/leads/
  services/deals/
  services/emails/
  dashboards/
  libs/auth/
  libs/db/
  migrations/

Authentication & Security Rules:
- Auth: JWT with short-lived access and rotation refresh tokens
- RBAC: admin, manager, user; enforce in middleware
- Data protection: encrypt PII at rest, use TLS, rotate keys, minimal permissions

Database and ORM patterns:
- PostgreSQL with row-level security for multi-tenant isolation
- Use repository pattern with explicit SQL for critical paths; avoid ORM black boxes in core pipelines
- Migrations via plain SQL scripts; versioned and auditable

Testing & Linting Workflows:
- Unit tests with Jest; coverage goals > 80%
- Integration tests using SuperTest for API routes
- Linting and type checks in CI; run Prettier formatting checks

Prohibited Actions and Anti-patterns for the AI:
- Do not execute raw user input as database commands
- Do not bypass security checks or RBAC
- Do not embed secrets in code or config
- Do not couple tenant data with global tables without a filter
- Do not generate production-ready code without tests

Recommended Project Structure

root/
  apps/
    api/
      src/
        index.ts
        routes/
        controllers/
        models/
        services/
        middleware/
        config/
      package.json
  services/
    leads/
    deals/
    emails/
  dashboards/
  libs/
    auth/
    db/
  migrations/

Core Engineering Principles

Security by default with explicit RBAC and data isolation
Explicit data contracts and well-defined boundaries between services
Deterministic, testable AI-assisted code with comprehensive tests
Simplicity in architecture to minimize surface area for bugs
Observability through structured logging, metrics, and tracing

Code Construction Rules

All database access uses parameterized queries and explicit schemas
API routes validate input against schemas; no blind pass-through
Tenant isolation must be enforced at the data layer with row-level security
Lead scoring and email tracking logic must be auditable and reversible
AI-generated outputs must be stored with provenance and revision history

Security and Production Rules

Use TLS for all endpoints; enable certificate rotation
Store secrets in a managed vault; do not hard-code keys
Rotate JWT signing keys and use short-lived access tokens
Regularly audit permissions and remove unused scopes
Back up critical data and test disaster recovery procedures

Testing Checklist

Unit tests cover domain logic for lead scoring and deal stage transitions
Integration tests verify API endpoints and email tracking workflows
End-to-end tests simulate multi-tenant user journeys in CI
Linting and type checks run on every commit
Security tests include RBAC validation and data access guards

Common Mistakes to Avoid

Overloading AI with domain logic that should be codified in rules
Neglecting tenant isolation and RBAC in critical paths
Hard-coding secrets or credentials in code or config
Skipping migrations or bypassing version control for DB changes
Relying on client-side validation for security-critical checks

Related Cursor rules templates

Explore adjacent Cursor rules templates for similar stacks, workflows, and production constraints.

FAQ

What is a Cursor Rules Template for a Sales Pipeline SaaS?

A Cursor Rules Template defines a structured set of rules that Cursor AI follows to assist in building and maintaining a multi-tenant sales pipeline software. It codifies architecture, security, testing, and coding standards for a stack involving Node.js, PostgreSQL, lead scoring, email tracking, deal stages, dashboards, and AI summaries.

Which stack is this Cursor Rules Template built for?

It targets a Node.js backend with PostgreSQL, designed for multi-tenant SaaS CRM workflows that include lead scoring, email tracking, deal stages, dashboards, and AI summaries generated by Cursor AI.

How do I apply this template to my project?

Copy the code block inside the Copyable .cursorrules Configuration section into your project root as .cursorrules. Adjust tenant settings, environment variables, and directory paths to match your repository structure and deploy safely to production.

What security considerations are included?

The template emphasizes RBAC, multi-tenant data isolation with row-level security, encrypted sensitive fields, TLS, and auditable changes. It also prescribes secure secret management and regular access reviews.

What tests are included in the testing checklist?

The checklist covers unit tests for core domain logic, integration tests for API endpoints and services, and end-to-end tests for real user journeys, all integrated into CI with linting and type checks.

Target User

Use Cases