Cursor Rules Template: Rental Marketplace with Property Listings, Applications, Tenant Screening, Payments and Messaging

Overview

The Cursor rules configuration provided here is a Cursor AI pattern designed for a rental marketplace stack. It targets a Node.js/Express backend (TypeScript) with PostgreSQL for data, real-time messaging, and PCI-conscious payments. The template includes a copyable .cursorrules block you can paste at your project root to guide Cursor AI in generating consistent code, data models, API specs, and guardrails for property listings, applications, tenant screening, payments, and tenant messaging.

Direct answer: paste the .cursorrules block into your project root to enforce stack-specific code generation, validation, and safe AI-assisted development across the rental marketplace domain.

When to Use These Cursor Rules

• Starting a rental marketplace project with property listings and tenant applications.
• Integrating payments and a compliant payment flow.
• Implementing tenant screening with consent-based data handling.
• Adding real-time messaging between landlords and tenants.
• Establishing CI/CD, tests, and linting rules to maintain code quality.

Copyable .cursorrules Configuration

/* Cursor Rules Block for Rental Marketplace (Node.js/Express + PostgreSQL) */
FRAMEWORK: Node.js/Express (TypeScript)
STACK: PostgreSQL, WebSocket messaging, PCI-conscious payments
CONTEXT: Rental marketplace with properties, applications, tenant screening, payments, and landlord-tenant messaging. Cursor AI assists backend APIs, data models, and guardrails; use strict validations and safe defaults.
ROLE: You are Cursor AI, helping generate robust backend services, data schemas, and guardrails for a scalable rental marketplace.
STYLE: TypeScript, ESLint, Prettier, Airbnb rules, explicit typings, no implicit any
ARCHITECTURE: Layered architecture (Controllers, Services, Repositories, Models). Mapped to src/ structure below
DIRS: src/controllers/, src/services/, src/repositories/, src/models/, src/routes/, src/middlewares/, src/config/, src/migrations/, src/tests/
AUTH: JWTs in httpOnly cookies with short-lived access tokens; refresh tokens rotated; 2FA optional for admin
DB: PostgreSQL with a repository pattern; explicit transactions for multi-step writes; soft deletes where appropriate
ENV: Do not commit secrets; use environment variables; load via config service
PAYMENTS: Stripe-like API integration; store Payment intents and status; protect keys; webhooks validated server-side
MESSAGING: Real-time via WebSocket or SSE; messages stored in DB; events emitted after write
SCREENING: Tenant screening with user consent; redact PII in logs; separate checks behind consent gate
TESTING: Jest for unit/integration tests; ESLint + Prettier; CI checks on PRs
ANTI: Do not execute user-provided code; Do not bypass validations; Do not log sensitive data; Do not expose private keys

Recommended Project Structure

project-root/
├─ src/
│  ├── controllers/
│  │   ├─ PropertyController.ts
│  │   ├─ ApplicationController.ts
│  │   ├─ ScreeningController.ts
│  │   ├─ PaymentController.ts
│  │   └─ MessageController.ts
│  ├── models/
│  │   ├─ Property.ts
│  │   ├─ Application.ts
│  │   ├─ Tenant.ts
│  │   ├─ Payment.ts
│  │   └─ Message.ts
│  ├── repositories/
│  │   ├─ PropertyRepository.ts
│  │   ├─ ApplicationRepository.ts
│  │   ├─ TenantRepository.ts
│  │   ├─ PaymentRepository.ts
│  │   └─ MessageRepository.ts
│  ├── services/
│  │   ├─ PropertyService.ts
│  │   ├─ ApplicationsService.ts
│  │   ├─ ScreeningService.ts
│  │   ├─ PaymentService.ts
│  │   └─ MessagingService.ts
│  ├── routes/
│  │   ├─ propertyRoutes.ts
│  │   ├─ applicationRoutes.ts
│  │   ├─ screeningRoutes.ts
│  │   ├─ paymentRoutes.ts
│  │   └─ messageRoutes.ts
│  ├── middlewares/
│  │   ├─ auth.ts
│  │   └─ error.ts
│  ├── config/
│  │   ├─ database.ts
│  │   ├─ api.ts
│  │   └─ secrets.ts
│  ├── migrations/
│  │   └─ 20260527_initial.sql
│  └── tests/
│      ├─ unit/
│      └─ integration/
└─ package.json

Core Engineering Principles

• Define clear API contracts and data schemas; let Cursor AI generate code against them.
• Type-safe, explicit code with runtime validation and minimal dynamic typing.
• Privacy by default; never log PII; restrict data access by role.
• Guardrails and fail-fast validation for all inputs and external calls.
• Idempotent operations for retries and resilient workflows (payments, applications).
• Explicit error handling with meaningful messages and status codes.
• Observability through structured logging, metrics, and tracing in CI/CD.
• Security-first deployment practices and secret management.

Code Construction Rules

• Endpoints must be RESTful and versioned; follow resource-oriented naming (properties, applications, tenants, payments, messages).
• Use explicit TypeScript types for all public APIs; validate inputs at the boundary using runtime validators.
• Database access through repositories with transactions for multi-step writes.
• Avoid global state; keep side effects isolated to services.
• Do not bypass authentication; require authorization for all protected routes.
• Do not log full credit card numbers or PII; redact sensitive fields.
• Use parameterized queries; never concatenate user input into SQL.
• CI should run linting, type checks, unit tests, and integration tests on PRs.
• Do not use client-side secrets; store and manage them securely in environment variables.

Security and Production Rules

• Transport security via TLS; enforce secure cookies and proper CORS configuration.
• Implement rate limiting, IP blocking, and input sanitization to prevent abuse.
• Validate Stripe-like webhook signatures server-side; verify event integrity.
• Protect endpoints with robust authentication and proper authorization checks.
• Use secret management for keys; rotate credentials regularly; monitor for suspicious activity.
• Data privacy: segment tenant screening data and restrict access by role; audit trails for critical actions.

Testing Checklist

• Unit tests for validators, data models, and small service functions.
• Integration tests for property, application, screening, payment, and messaging endpoints.
• End-to-end tests for a rental workflow: create property, apply, screen, charge payment, send message.
• Security tests: input validation, auth/authorization, rate limiting checks.
• CI/CD checks on push with linting, type checks, and test coverage thresholds.

Common Mistakes to Avoid

• Omitting input validation at the API boundary.
• Storing sensitive data without proper encryption or masking in logs.
• Assuming client-side validation is sufficient; always validate server-side.
• Ignoring concurrency and transaction consistency in multi-step workflows (applications, payments).
• Not accounting for tenant privacy during screening data processing.

Related Cursor rules templates

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

• Cursor Rules Template for Node.js Hotel Booking Platform
• Cursor Rules Template: Cash Flow SaaS with Bank Imports, Invoices, and AI Predictions
• Cursor Rules Template: LMS with Courses, Lessons, Quizzes, Certificates, Payments, and Admin Dashboard
• Cursor Rules Template: SaaS Revenue Dashboard (MRR, ARR, Churn & Cohorts)

FAQ

What is the Cursor Rules Template for a rental marketplace?

This Cursor Rules Template provides a ready-to-paste .cursorrules block and stack-specific guidance to configure Cursor AI for a rental marketplace. It covers properties, applications, tenant screening, payments, and messaging with security-focused guardrails and testing workflows.

Which stack does this template target?

The template targets a Node.js/Express backend with TypeScript, PostgreSQL for data, WebSocket messaging, and a Stripe-like payments flow; it emphasizes safe AI-assisted development within that stack.

How do I use the .cursorrules configuration?

Copy the block under Copyable .cursorrules Configuration and paste it into the root of your project as .cursorrules. Cursor AI will use it to guide code generation, validation, and guardrails for the rental marketplace features.

Can I adapt the rules to another stack?

Yes, adjust framework, data layer, authentication, and messaging components in the Rule block to reflect your stack while preserving the guardrail structure and testing approach.

What should I include in the recommended project structure?

Include a layered architecture with controllers, services, repositories, models, routes, middlewares, config, migrations, and tests. The structure shown mirrors a typical Node.js/Express TypeScript project and is designed for maintainability and CI/CD.