Cursor Rules Template: Property Management SaaS Stack

Overview

Cursor rules configuration provides a guided, executable set of constraints for Cursor AI to assist developers building a multi-tenant property management SaaS. This template targets a stack based on Python FastAPI, SQLAlchemy, and PostgreSQL, covering tenants, leases, rent payments, maintenance tickets, and owner reports. It defines roles, data models, workflows, and safety constraints so AI-assisted development remains predictable and auditable.

When to Use These Cursor Rules

Starting a property management MVP with clear tenant and lease data models.
Implementing multi-tenant data isolation with ORM-based access control.
Guiding AI-driven code generation for payments, maintenance, and reporting flows.
Enforcing security, validation, and testing standards from day one.
Documenting project structure and CI/CD steps for a SaaS stack.

Copyable .cursorrules Configuration

framework: python-fastapi-sqlalchemy
frameworkVersion: 1.x

# Framework Role & Context
role: Cursor AI assistant for a multi-tenant Property Management SaaS using Python FastAPI + SQLAlchemy + PostgreSQL
context: You help engineers implement tenants, leases, rent payments, maintenance tickets, and owner reports. Provide safe, testable, and maintainable guidance.

# Code Style and Style Guides
codeStyle: pep8, black, isort, mypy
namingConventions: snake_case for DB and Python identifiers
linters: ruff, flake8 (where applicable)

# Architecture & Directory Rules
projectRoot: app
modules:
  - core
  - models
  - api/v1
  - services
  - db/migrations

# Authentication & Security Rules
auth: OAuth2 with JWT
authorization: token-based access for tenant vs admin endpoints
security: TLS in transit, AES-256 at rest, secret management via env vars

# Database and ORM patterns
db: PostgreSQL
orm: SQLAlchemy
models:
  - Tenant
  - Lease
  - RentPayment
  - MaintenanceTicket
  - OwnerReport
relationships:
  Tenant 1..* Lease
  Lease 1..* RentPayment
  Lease 1..* MaintenanceTicket
  Lease 1..* OwnerReport

# Testing & Linting Workflows
tests: pytest + pytest-asyncio
linting: ruff + black
ci: unit, integration, and migration checks

# Prohibited Actions and Anti-patterns for the AI
doNot:
  - operate outside the app/db boundaries
  - generate raw SQL outside ORM when not needed
  - embed secrets or credentials in code blocks
  - bypass authentication checks
  - implement business logic in endpoints without services

# Example guidance for common ops
notes:
  - Use explicit transactions for multi-step operations
  - Avoid N+1 by using joinedload/selectinload
  - Validate inputs via Pydantic models

Recommended Project Structure

project/
├── app/
│   ├── main.py
│   ├── api/
│   │   └── v1/
│   │       ├── endpoints/
│   │       │   ├── tenants.py
│   │       │   ├── leases.py
│   │       │   ├── payments.py
│   │       │   ├── tickets.py
│   │       │   └── reports.py
│   │       └── schemas.py
│   ├── core/
│   │   ├── config.py
│   │   ├── security.py
│   │   └── logging.py
│   ├── models/
│   │   ├── tenant.py
│   │   ├── lease.py
│   │   ├── payment.py
│   │   ├── maintenance.py
│   │   └── owner_report.py
│   ├── services/
│   │   ├── payments.py
│   │   ├── leases.py
│   │   ├── tickets.py
│   │   └── reports.py
│   └── db/
│       ├── base.py
│       └── migrations/
├── tests/
├── alembic.ini
├── requirements.txt
└── .env

Core Engineering Principles

Bounded contexts and explicit boundaries between Tenant, Lease, Payments, Tickets, and Reports domains.
Strong typing and validation using Pydantic, with clear API contracts.
Idempotent write operations and explicit database transactions for consistency.
Security by default: least privilege, token-based auth, and secrets managed via environment.
Observability: structured logging, metrics, and traces for critical workflows.
Test-first mindset: unit, integration, and migration tests included in CI.

Code Construction Rules

Model definitions live in app/models with clear foreign key relationships for Tenant, Lease, RentPayment, MaintenanceTicket, and OwnerReport.
All endpoints require authentication; authorization gates enforce read/write access per role.
Use Pydantic schemas for request/response validation; avoid leaking internal fields.
Database access via SQLAlchemy ORM; minimize raw SQL and use expressions only when necessary.
Prevent N+1 queries by eager loading and proper session management.
Tests cover the full call chain: models, services, and API endpoints.
Do not hard-code IDs; rely on DB-generated keys and deterministic tests.

Security and Production Rules

Use TLS for all endpoints; store secrets in environment variables or a vault.
JWT tokens must include short expiration and refresh tokens with revocation checks.
Role-based access control enforced at service boundaries; audit admin actions.
Rate limiting on public endpoints and anomaly detection for failed auth attempts.
Encrypt sensitive fields at rest; ensure backups are secure and test restore procedures.

Testing Checklist

Unit tests for models and services with in-memory or test databases.
Integration tests for API endpoints using a test client and a test DB.
Migration tests to ensure Alembic scripts apply cleanly in CI.
Security tests for authentication and authorization rules.
End-to-end tests for common flows: tenant onboarding, lease creation, rent posting, ticket creation, and report generation.

Common Mistakes to Avoid

Mixing business logic into API handlers rather than in services.
Ignoring time zones in rent due dates and reports.
Skipping migrations or relying on destructive schema changes in production.
Storing raw import data without validation leading to data integrity issues.
Over-reliance on ORM lazy loading causing N+1 queries.

Related Cursor rules templates

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

FAQ

What stack is this Cursor Rules Template designed for?

This template targets a Python FastAPI + SQLAlchemy + PostgreSQL stack for a multi-tenant property management SaaS. It defines data models, workflows, and safety constraints to guide AI-assisted development.

Can I adapt these rules to other frameworks?

Yes. The rules are stack-specific but can be adapted to similar stacks with equivalent ORM and API patterns, keeping the same architectural and security constraints in mind.

How do you handle multi-tenancy in the rules?

The rules enforce tenant isolation through scoped models, explicit tenant_id relationships, and middleware that enforces access checks on every operation.

How do I run the tests and migrations?

Use your CI to run pytest for unit and integration tests, and execute Alembic migrations on a test database before merging. Ensure the test DB is reset between runs.

What are the anti-patterns this template blocks?

It blocks raw SQL in business logic, hard-coded IDs, insecure secret handling, and bypassing authentication. It enforces explicit transactions and proper error handling for all critical paths.

Where can I extend or customize the rules?

Extend the rules in the service layer and dedicated API endpoints under app/api/v1. Add new domain modules (for example Property or Building) with standalone models and services while preserving bounded contexts.

Target User

Use Cases