Cursor Rules Template: Restaurant Reservation SaaS with Node.js Stack

Overview

Cursor rules configuration for building a restaurant reservation SaaS using a Node.js stack (Express, PostgreSQL, Sequelize). This copyable Cursor rules template defines architecture, coding standards, data patterns, and safe AI usage for deposits and reminders. Direct answer: paste the included .cursorrules configuration into your project root to enforce stack-specific guidance and consistent outputs from Cursor AI.

Stack: Node.js + Express + PostgreSQL + Sequelize
Output: Copyable .cursorrules block and stack-specific project guidance
Scope: Tables, time slots, guest profiles, deposits, reminders, and notifications

When to Use These Cursor Rules

Starting a new restaurant reservation SaaS project with a clean, scalable architecture
Standardizing data models across tenants (restaurants) and ensuring consistent business rules
Enforcing security best practices for authentication, deposits, and payment tokens
Guiding Cursor AI to generate stack-appropriate code and scaffolding

Copyable .cursorrules Configuration

framework_role: Backend Engineer
context: Restaurant reservation SaaS with tables, time slots, guest profiles, deposits, reminders on Node.js Express PostgreSQL Sequelize
stack: Node.js, Express, PostgreSQL, Sequelize
framework: Node.js/Express
code_style: ECMA 2020, ESLint, Prettier
architecture: Layers - controllers, services, models, routes, db/migrations, db/seeders
directory_rules:
  - app/controllers
  - app/services
  - app/models
  - app/routes
  - app/db/migrations
  - app/db/seeders
auth_security:
  - JWT-based authentication
  - bcrypt for password hashing
  - TLS/HTTPS in production
  - secure cookies and token storage
db_orm:
  - database: postgres
  - orm: Sequelize
  - tables: users, restaurants, tables, slots, reservations, deposits, guests
  - migrations and seeders enabled
validation_and_testing:
  - input validation with Joi
  - tests with Jest
  - integration tests with Supertest
  - linting in CI
testing_and_ci:
  - unit tests for services
  - integration tests for endpoints
  - CI: run jest and eslint
prohibited_actions:
  - Do not use raw SQL in app code
  - Do not store raw card data; use tokenization via payment gateway
  - Do not bypass ORM abstractions
  - Do not hard-code secrets; use environment variables

Recommended Project Structure

restaurant-reservation-saas/
├── app/
│   ├── controllers/
│   │   └── reservationController.js
│   ├── models/
│   │   └── reservation.js
│   ├── routes/
│   │   └── reservationRoutes.js
│   ├── services/
│   │   └── reservationService.js
│   ├── middlewares/
│   │   └── authMiddleware.js
│   └── db/
│       ├── migrations/
│       │   └── 20260527-create-reservation.js
│       └── seeders/
│           └── seed-reservation.js
├── config/
│   └── db.js
└── tests/
    ├── unit/
    └── integration/

Core Engineering Principles

Stack-appropriate layering: API layer, domain logic, and data access must be clearly separated
Idempotent operations for reservations and deposits to prevent duplicate actions
Validation at every boundary (requests, business rules, and persistence)
Security by default: authentication, authorization, and secure data handling
Observability: structured logging, tracing, and metrics for critical paths
Deterministic behavior with explicit error handling and retry strategies

Code Construction Rules

Use Express Router per resource; avoid a single monolithic app.js
Model entities: users, restaurants, tables, slots, reservations, deposits, guests
Use Sequelize migrations for schema changes; seeders for initial data
Validate all inputs with Joi and return consistent error shapes
Reservation creation checks time-slot availability; race conditions prevented via transactions
Deposit handling uses tokenized payment flows; never store raw card data
Do not sprinkle business logic in controllers; delegate to services
Do not bypass ORM abstractions; use parameterized queries via the ORM

Security and Production Rules

TLS/HTTPS in production; keep secrets in environment variables
JWT-based auth with short-lived access tokens and refresh tokens
Rate limiting and IP throttling to mitigate abuse
Secure cookies, CSRF protection, and proper CORS settings
Data minimization for PII and compliance-ready by design

Testing Checklist

Unit tests for services and validators
Integration tests for REST endpoints and data access
Database migrations tested in CI with a fresh PostgreSQL instance
Linting and type checks run on PRs
Smoke tests for deployment readiness

Common Mistakes to Avoid

Storing or bypassing payment card data; rely on tokenization
Underestimating time-zone handling for slots and reservations
Hard-coding secrets or credentials in code
Skipping migrations or seeding in development/CI environments
Overloading controllers with business logic

Related Cursor rules templates

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

FAQ

What is included in this Cursor Rules Template?

This template provides a complete, pasteable .cursorrules block and stack-specific guidance for building a restaurant reservation SaaS using Node.js, Express, PostgreSQL, and Sequelize. It covers architecture, security, data models, and testing patterns so Cursor AI can generate consistent code and recommendations.

How do I apply the copyable .cursorrules block?

Copy the content under Copyable .cursorrules Configuration and place it in a new file named .cursorrules at your project root. Cursor AI will then constrain future outputs to this stack and ruleset, ensuring consistent architecture and patterns.

Can this template support multi-tenant deployments?

Yes. The rules emphasize scoping reservations, slots, and deposits by restaurant per tenant, with per-restaurant data isolation, validation, and authorization boundaries. Extend the models to include tenant_id and enforce tenant-aware queries in ORM interactions.

How is time zone handling addressed?

Time zones should be stored in UTC in the database and converted to the restaurant's local time at the API boundary. Cursor rules enforce consistent slot calculations, timezone-aware formatting, and user preferences for display times.

Where should I place the .cursorrules file in my repo?

Place the .cursorrules file at the repository root alongside package.json. This ensures Cursor AI applies the rules to all generated code and documentation within the project, maintaining stack-specific guidance across modules.

Target User

Use Cases