Cursor Rules Template: SaaS Revenue Dashboard (MRR, ARR, Churn & Cohorts)

Overview

Cursor rules configuration for a SaaS revenue dashboard backend that tracks MRR, ARR, churn, and cohort analytics. Stack: Node.js (Express) backend, PostgreSQL database, and Cursor AI for rule-driven API and data transformations. Direct answer: this Cursor Rules Template provides a concrete, copyable .cursorrules block and a stack-specific project scaffold to accelerate production-ready revenue analytics development.

When to Use These Cursor Rules

• When building a revenue analytics dashboard for a SaaS product with metrics like MRR, ARR, churn, and cohorts.
• When you want explicit data contracts between backend services and analytics frontend components.
• When enforcing security, testing, and linting across API endpoints and data access layers.
• When prototyping SQL patterns and API contracts with Cursor AI while maintaining production-grade structure.

Copyable .cursorrules Configuration

// Cursor Rules Template for NodeExpressPostgres SaaS Revenue Dashboard

Framework Role & Context:
You are Cursor AI acting as Backend Architect for a Node.js (Express) + PostgreSQL stack. Your job is to generate precise API contracts and SQL patterns to support MRR, ARR, churn, and cohort analytics for a SaaS revenue dashboard.

Code Style and Style Guides:
Language: TypeScript
Lint: ESLint with Airbnb style
Formatter: Prettier
Testing: Jest
Type Checking: TypeScript

Architecture & Directory Rules:
Backend: backend/
  src/
    controllers/
    routes/
    services/
    db/
      migrations/
      seeds/
Frontend: frontend/
  src/
    pages/
    components/
    hooks/
    services/

Authentication & Security Rules:
Use JWT Bearer tokens; validate tokens in middleware; do not store secrets in code; implement RBAC with roles: admin, analyst, viewer; sanitize inputs.

Database and ORM patterns:
Database: PostgreSQL
ORM: Do not use an ORM; use node-postgres (pg) with parameterized queries. Migrations stored in backend/db/migrations. Use a repository pattern for data access.

Testing & Linting Workflows:
Unit tests: Jest
Integration tests: Supertest for API endpoints
Lint: npm run lint
CI: run tests and lint on PRs

Prohibited Actions and Anti-patterns for the AI:
Do not generate unsafe SQL concatenation; Do not bypass authentication; Do not mutate data outside service layers; Do not rely on ORM frameworks; Do not expose credentials in code.

Recommended Project Structure

backend/
├── src/
│   ├── controllers/
│   │   └─ revenue.js
│   ├── routes/
│   │   └─ revenueRoutes.js
│   ├── services/
│   │   └─ revenueService.js
│   ├── db/
│   │   ├── migrations/
│   │   │   └─ 001_init.sql
│   │   └── index.js
│   └── tests/
│       └─ revenue.test.js
├── package.json

frontend/
├── src/
│   ├── components/
│   │   └─ DashboardCard.jsx
│   ├── pages/
│   │   └─ dashboard.jsx
│   ├── hooks/
│   │   └─ useDashboard.js
│   └── services/
│       └─ apiClient.js
├── package.json

shared/
└── config/
    └─ dbConfig.js

Core Engineering Principles

• Data contracts are explicit and versioned.
• Endpoint operations are idempotent and auditable.
• Security-first by default: authentication, authorization, least privilege.
• Typed data and robust input validation to prevent runtime errors.
• Separation of concerns: backend data access, business logic, and API surface.
• Observability: structured logs, metrics, and tracing for revenue metrics.

Code Construction Rules

• Use parameterized queries for all SQL to prevent injection.
• Compute MRR/ARR and churn at the database layer where possible for performance.
• Frontend requests should fetch aggregated revenue metrics via backend endpoints, not raw data tables.
• All secrets must be stored in environment variables and loaded via a secret manager in production.
• Do not use an ORM; rely on a repository pattern with raw SQL in a dedicated module.

Security and Production Rules

• Enforce TLS, rotate credentials, and audit access to revenue data endpoints.
• Implement rate limiting and IP allowlists for sensitive APIs.
• Hash and salt sensitive data where stored; avoid exporting PII in logs.
• Use feature flags for rollout of new analytics features to minimize risk.

Testing Checklist

• Unit tests for data access and transformation logic.
• Integration tests for API endpoints delivering MRR/ARR/cohort data.
• End-to-end tests simulating dashboard usage with mock data.
• Lint and type-check in CI; ensure no TS compilation errors.

Common Mistakes to Avoid

• Hardcoding sample data in production code; use fixtures or mocks.
• Skip input validation, leading to SQL injection surface.
• Mix business logic with routing; keep services thin and testable.
• Neglect migrations or produce divergent schema changes across environments.

Related Cursor rules templates

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

• Cursor Rules Template: AI Tutor SaaS Stack
• Cursor Rules Template: Sustainability Supplier Assessment Platform with Questionnaires, Scoring, and Compliance Dashboards
• Cursor Rules Template: Construction Project Management Stack
• Cursor Rules Template: SaaS Metrics Dashboard with Stripe Integration

FAQ

What is a Cursor Rules Template?

A Cursor Rules Template provides a copyable .cursorrules block and a stack-specific project scaffold to guide AI-assisted development for a given tech stack.

Which stack does this template target?

This template targets a Node.js (Express) backend with PostgreSQL, a TypeScript codebase, and a frontend dashboard. Cursor AI uses rule blocks to shape API contracts, SQL queries, and test scaffolds for SaaS revenue analytics.

How do I paste this into a .cursorrules file?

Copy the code block under Copyable .cursorrules Configuration into a file named .cursorrules in your project root. Cursor AI will interpret the sections to produce backend patterns and tests.

Can I adapt this for other databases?

Yes, but adjust the SQL dialects, migrations, and connection strings when moving away from PostgreSQL while preserving validation, security, and data contracts.

Is authentication included?

Yes. The template enforces JWT-based authentication with RBAC. Middleware validates tokens; access decisions live in the service layer.

How do I test the revenue metrics?

Use unit tests for data fetchers, integration tests for endpoints delivering MRR/ARR/cohort data, and end-to-end tests to validate dashboard behavior with mock data. Cursor rules help ensure predictable, testable outputs.