Cursor Rules Template: Real Estate CRM with Leads, Listings, Tours, Follow-ups, Documents and Agent Dashboards

Overview

Direct answer: This Cursor Rules Template provides a complete, copyable Cursor rules block for building a real estate CRM stack that handles leads, listings, property tours, follow-ups, documents, and agent dashboards. It targets a modern web stack (Next.js frontend, Node.js API, PostgreSQL database) and includes security, testing, and governance guidance to keep the AI-assisted development safe and maintainable.

The Cursor rules configuration is designed to be dropped into your project root as a .cursorrules file and used by Cursor AI to scaffold, validate, and guide development across modules: leads, listings, tours, documents, and agent dashboards. It enforces architecture, naming, and security constraints while providing concrete implementation constraints for engineers.

When to Use These Cursor Rules

• Starting a real estate CRM project with a clear module boundary: leads, listings, tours, documents, and agents.
• Enforcing data models, API contracts, and directory structure across frontend and backend codebases.
• Guiding secure authentication, authorization, and audit trails for agent access and admin control.
• Preventing architecture drift by codifying architecture & directory rules for a Next.js + Node + PostgreSQL stack.
• Pairing Cursor AI prompts with robust testing and linting workflows for production reliability.

Copyable .cursorrules Configuration

# Cursor Rules Template for Real Estate CRM (Cursor AI)
Framework Role & Context:
  - Role: 'Cursor AI assistant for a Full-Stack Real Estate CRM stack (Leads, Listings, Tours, Follow-ups, Documents, Agent Dashboards)'
  - Context: 'Frontend: Next.js; Backend API: Node.js; Database: PostgreSQL; Auth: JWT + HttpOnly cookies; Cursor AI usage: scaffold, validate, and govern code with safe practices.'

Code Style and Style Guides:
  - Language: 'TypeScript'
  - Style: 'ESLint + Prettier; 2-space indentation; explicit types; no eval'

Architecture & Directory Rules:
  - apps/api/src/modules/leads
  - apps/api/src/modules/listings
  - apps/api/src/modules/tours
  - apps/api/src/modules/documents
  - apps/api/src/modules/followups
  - apps/api/src/modules/agents
  - apps/web/src/pages
  - apps/web/src/components
  - db/migrations

Authentication & Security Rules:
  - Strategy: 'JWT with HttpOnly cookies; refresh tokens; CSRF tokens'
  - Access control: 'RBAC with roles: admin, agent, viewer'
  - Secrets: 'Do not embed secrets in client code; use environment variables or a vault'
  - Data privacy: 'Mask PII in logs; enforce field-level encryption where applicable'

Database and ORM patterns:
  - DB: 'PostgreSQL; normalized schema; migrations; indexes on leads.status, tours.date, listings.city'
  - ORM/Query: 'Use parameterized queries; avoid string concatenation; prefer prepared statements'

Testing & Linting Workflows:
  - Unit: 'Vitest/Jest for backend; React Testing Library for frontend'
  - Integration: 'Supertest for API; Cypress for UI flows'
  - Lint: 'CI lint step with ESLint/Prettier; type-check with TypeScript'

Prohibited Actions and Anti-patterns for the AI:
  - 'Do not bypass authentication or authorization checks'
  - 'Do not introduce client-side security controls as replacements for server checks'
  - 'Do not emit secrets or credentials in prompts or outputs'
  - 'Do not generate production database credentials or connection details in prompts'
  - 'Do not relax validation or rely on optimistic locking to bypass constraints'

Recommended Project Structure

/
├── apps
│   ├── api
│   │   └── src
│   │       ├── modules
│   │       │   ├── leads
│   │       │   ├── listings
│   │       │   ├── tours
│   │       │   ├── documents
│   │       │   ├── followups
│   │       │   └── agents
│   │       └── index.ts
│   ├── web
│   │   └── src
│   │       ├── pages
│   │       ├── components
│   │       └── hooks
│   └── README.md
├── db
│   ├── migrations
│   └── seeds
└── scripts
    ├── migrate.ts
    └── seed.ts

Core Engineering Principles

• Clarity in data models and API contracts to reduce ambiguity between frontend and backend.
• Idempotent and auditable operations for CRM actions (lead updates, tour bookings, document uploads).
• Secure-by-default configurations with RBAC and robust validation at every boundary.
• Separation of concerns between UI, API, and data access layers.
• Observability through structured logging, metrics, and tracing for production issues.

Code Construction Rules

• Use TypeScript end-to-end; avoid dynamic typing in API routes; export typed interfaces for entities.
• Follow a modular API design: leads, listings, tours, documents, followups, agents modules.
• Endpoints must validate inputs with schema validation and return consistent error shapes.
• Directory structure must be stable and documented in the Cursor rules block to prevent drift.
• Avoid duplicating business logic; share utilities in a common lib module.

Security and Production Rules

• Authenticate requests with HttpOnly JWT cookies; rotate tokens on demand.
• Enforce RBAC: admin, agent, viewer; protect sensitive data like client PII and agreement docs.
• Validate all inputs server-side; sanitize files uploaded to document storage; implement size/type restrictions.
• Enable auditing: log create/update/delete actions with user context and timestamps.
• Keep secrets out of code; use environment vars and a secret management solution in production.

Testing Checklist

• Unit tests for all modules (leads/listings/tours/documents/followups/agents) with typed inputs.
• Integration tests for API routes and data access; ensure RBAC enforcement is exercised.
• UI tests for agent dashboards and listing flows; verify lease and tour booking workflows.
• Static analysis and linting in CI; run type checks and formatting checks on PRs.
• Performance checks on common read paths (leads and listings list retrieval) with realistic data volumes.

Common Mistakes to Avoid

• Assuming client-side validation is sufficient; always enforce server-side validation.
• Hard-coding secrets or credentials in code or prompts.
• Inconsistent directory naming leading to architectural drift between modules.
• Neglecting RBAC edge cases for nested resources (e.g., documents tied to a specific agent).
• Neglecting tests for the document upload flow and notification triggers.

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: Rental Marketplace with Property Listings, Applications, Tenant Screening, Payments and Messaging
• Cursor Rules Template for Vendor Management SaaS (Contracts, Compliance, Renewals, AI Risk)
• Cursor Rules Template: Construction Project Management Stack

FAQ

What is the purpose of a Cursor Rules Template for a Real Estate CRM?

The template provides concrete, copyable rules to guide Cursor AI in scaffolding and governing a real estate CRM stack, ensuring architecture, security, and testing practices align with the Leads/Listings/Tours/Docs/Agent dashboards domain.

Which stack does this template target?

The template targets a modern web stack with a Next.js frontend, a Node.js API backend, and a PostgreSQL database, focusing on maintainable module boundaries and secure data flows for real estate workflows.

What should I copy into .cursorrules for my project?

Copy the entire Copyable .cursorrules Configuration block into a file named .cursorrules at your project root. It includes framework role, code style, architecture rules, authentication, database patterns, testing workflows, and anti-patterns.

How do I adapt the rules to my deployment environment?

Replace placeholder values (e.g., module paths, environment-specific endpoints) with your project’s actual file layout and service endpoints while preserving the strict security and testing constraints defined in the template.

Can Cursor AI enforce security validations automatically?

Yes. The rules require server-side validation, RBAC checks, and auditing; Cursor AI can help scaffold secure endpoints but must rely on code-level implementations to enforce these protections.

What metrics should I monitor in production?

Monitor API latency for leads/listings queries, authentication error rates, audit-log volume, and document upload sizes; add dashboards to track agent activity and tour bookings for operational insight.