Cursor Rules Template: SaaS Metrics Dashboard with Stripe Integration

Overview

This Cursor rules configuration provides a production-ready blueprint for building a SaaS metrics dashboard that surfaces MRR, ARR, churn, retention, and cohort insights, with Stripe integration as the revenue source. It specifies a Next.js (TypeScript) frontend, a PostgreSQL data store, and a clear API boundary. The Cursor rules template includes a direct, copyable .cursorrules block to enforce stack-specific constraints and safe AI-assisted development.

Direct answer: Use this template to configure Cursor AI for a SaaS dashboard with Stripe integration. It defines architecture, security, data access, and testing patterns tailored to Next.js + PostgreSQL + Stripe.

When to Use These Cursor Rules

• Need to generate a consistent SaaS metrics dashboard with MRR, ARR, churn, retention, and cohort analytics.
• Integrating Stripe data (subscriptions, invoices, plans) into PostgreSQL for analytics.
• Enforcing architecture and security constraints across frontend, API, and data layers.
• Require repeatable, testable code generation and file scaffolding for new dashboard features.

Copyable .cursorrules Configuration

// Cursor Rules for SaaS Metrics Dashboard (Next.js + PostgreSQL + Stripe)
// Stack: Next.js (TypeScript), PostgreSQL, Stripe
Framework Role & Context:
- You are a Senior Full-Stack Engineer building a production-grade SaaS metrics dashboard.
- Stack: Next.js with TypeScript, PostgreSQL, Stripe; serverless API routes; using Cursor AI to shape code and policy.

Code Style and Style Guides:
- TypeScript strict, ESLint + Prettier, tsconfig strict, import/order, noImplicitAny, consistent naming.

Architecture & Directory Rules:
- App root: apps/web (frontend), apps/api (API), libs/db (DB access), libs/metrics (shared KPIs).
- Use src/pages, src/app, and api routes under a clear boundary.
- Data access through a dedicated db/ layer; avoid raw queries in UI.

Authentication & Security Rules:
- Use NextAuth for authentication; do not expose secrets to the client.
- Verify Stripe webhooks; store secrets in env vars; use CSRF protection on mutating endpoints.
- Enforce least privilege for DB roles and secret rotation.

Database and ORM patterns:
- PostgreSQL with node-postgres (pg). Prefer parameterized queries and explicit migrations.
- Data model: public.mrr, public.arr, public churn_logs, public cohorts, public subscriptions, public users.

Testing & Linting Workflows:
- Vitest for unit tests; Playwright for end-to-end tests; CI runs lint, type-check, and tests.
- Pre-commit hooks enforce formatting and basic tests.

Prohibited Actions and Anti-patterns for the AI:
- Do not bypass auth, ignore database rules, or generate client-side secrets.
- Do not emit raw SQL in client code; avoid N+1 query patterns; no insecure eval usage.

Stripe integration notes:
- Handle webhooks securely; idempotent handlers; reconcile invoices and subscriptions to MRR/ARR.
- Attribute revenue to cohorts by subscription dates and plan changes.

Recommended Project Structure

apps/
  web/        # Next.js frontend
  api/        # API routes for metrics andStripe events
libs/
  db/         # PostgreSQL client, migrations, models
  metrics/    # Shared KPI calculations and utilities
  stripe/     # Stripe event handlers and invoicing logic

Core Engineering Principles

• Data correctness and observability
• Security by default, least privilege
• Idempotent, auditable event processing
• Clear separation of concerns
• Deterministic CI/CD and migrations

Code Construction Rules

• All DB access uses parameterized queries; no string concatenation for SQL.
• Backend API routes validate input against defined schemas; avoid over-fetching.
• Use server components for sensitive logic; avoid leaking secrets to the client.
• Metrics calculations live in backend services with typed interfaces.
• Tracking, rate-limiting, and error handling are centralized and testable.

Security and Production Rules

• Stripe webhook verification with signed events.
• Environment variables and secrets stored securely; never in client code.
• HTTPS only, TLS termination, and secret rotation policies.
• Audit logs for data access and Stripe events; access controls for DB roles.

Testing Checklist

• Unit tests for data access and KPI functions.
• Integration tests for Stripe event handlers and DB writes.
• End-to-end tests for dashboard rendering and auth flows.
• CI checks: lint, type-check, tests, and migrations run on PRs.

Common Mistakes to Avoid

• Mixing frontend and backend concerns in a single module.
• Skipping input validation and trusting client data.
• Weak handling of Stripe webhooks or missing idempotency.
• Hard-coding secrets or using client-side DB credentials.

Related Cursor rules templates

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

• Cursor Rules Template — Real Estate Dashboard with Cash Flow, ROI, and Analytics
• Cursor Rules Template: SaaS Revenue Dashboard (MRR, ARR, Churn & Cohorts)
• Cursor Rules Template: Newsletter Platform with Subscriptions, Campaigns, Segmentation, Payments and AI Writing Assistant
• Cursor Rules Template: Django Subscription Box Platform

FAQ

What is a Cursor rules template?

A Cursor rules template codifies stack-specific guardrails and code-generation expectations for Cursor AI. It defines architecture constraints, security policies, testing workflows, and concrete implementation patterns that reduce drift and keep the SaaS dashboard project aligned with best practices.

What stack does this template cover?

This template focuses on a Next.js frontend with TypeScript, PostgreSQL for the database, and Stripe for billing data. It includes guidance for metrics calculations (MRR/ARR, churn, retention, cohorts) and Stripe event processing within a robust development workflow.

How do I use the .cursorrules block?

Copy the block into a file named .cursorrules at your repo root. Cursor AI will apply the rules to code generation, enforce architecture constraints, and remind you of security and testing steps during development.

What are the security considerations?

Verify Stripe webhooks, avoid leaking secrets on the client, and enforce authentication for API routes. Use environment variables, hash passwords, and limit DB access to the least privilege user. Maintain audit logs for critical actions.

How can I extend this template for additional metrics?

Extend the backend to compute new KPI metrics, update Stripe webhook handlers for new events, and keep the Cursor rules block updated. Maintain backward compatibility and document changes in the template.