Cursor Rules Template: Node/Nest Proposal SaaS with CRM Integration

Overview

This Cursor rules configuration provides a focused, stack-specific blueprint for building a proposal generation SaaS with CRM integration, AI proposal writing, templates, approvals, and PDF export. It targets a Node.js / NestJS backend with PostgreSQL and REST APIs, enabling automated proposal generation and CRM data flows via Cursor AI.

When to Use These Cursor Rules

When delivering AI-assisted proposals within a CRM-enabled SaaS.
When you need templates, approvals workflows, and PDF export in a single flow.
When you want a copyable, shareable .cursorrules configuration for rapid project bootstrap.

Copyable .cursorrules Configuration

.cursorrules
Framework: Node.js / NestJS
Context: You are engineering a SaaS for automated proposals with CRM integration. The AI will draft proposals, manage templates, support approval workflows, and export PDFs. Target runtime: Node.js 18+, PostgreSQL, REST APIs. Use Cursor AI to scaffold and enforce architecture.
Style: TypeScript, ESLint, Prettier, Airbnb-style rules
Architecture: Monorepo with apps/api, apps/web, libs/db, libs/core, libs/integration
Directory: /apps/api/src, /apps/web, /libs/db, /libs/core, /libs/integration
Auth: JWT access tokens, OAuth 2.0 for CRM integration, refresh tokens
Security: CSRF protection for APIs, input validation, parameterized queries, secret management
DB: PostgreSQL with schemas per bounded context, migrations, versioned migrations
ORM patterns: If used, prefer explicit query builders with strong typing; otherwise use plain SQL with parameter binding
Testing: Jest unit tests, integration tests with SuperTest, end-to-end tests with Cypress
Linting/Formatting: ESLint + Prettier; enforce on commit via hooks
Prohibited Actions: Do not bypass authentication, expose CRM secrets, use hardcoded credentials, or generate code that circumvents rate limits or audit logs

Recommended Project Structure

project-root/
├── apps/
│   ├── api/       # NestJS REST API for proposals, CRM sync, auth
│   │   └── src/
│   └── web/       # Next.js frontend for templates, approvals, PDF export
├──/libs/
│   ├── core/      # shared types, interfaces, constants
│   ├── db/        # PostgreSQL schema, migrations, seeds
│   └── integration/ # CRM connectors (Salesforce/HubSpot)
├── migrations/    # database migrations
├── tools/         # scripts and helpers

Core Engineering Principles

Separation of concerns across API, domain, and integration layers.
Security by default: validate input, sanitize, and enforce least privilege.
Strong typing and explicit data contracts between services.
Template-driven design with clear approval workflows and audit trails.
Idempotent operations for CRM syncing and PDF export.

Code Construction Rules

Strict TypeScript usage with strictNullChecks and noImplicitAny enabled.
API endpoints must have input schemas and rate-limiting enabled.
Database access uses parameterized queries; avoid string-concatenated SQL.
Templates and proposals stored in versioned formats; PDFs generated via a deterministic layout engine.
CI pipelines run unit tests, integration tests, and end-to-end checks before merge.
Do not embed CRM credentials in code or configuration files; use environment-based secrets.

Security and Production Rules

JWT or OAuth 2.0 with short-lived access tokens; rotate refresh tokens.
Audit logging for proposal actions and CRM data changes.
Rate limiting on public API endpoints; protect against mass export attacks.
Encrypt sensitive fields at rest; use secure storage for PDFs and templates.
Regular dependency scanning and patching; pin integration library versions.

Testing Checklist

Unit tests for business logic in proposals, templates, and approvals.
Integration tests for CRM sync and PDF export flows.
End-to-end tests for the full proposal lifecycle (draft, submit, approve, export).
Lint and type-check in CI; run security scanning tools.

Common Mistakes to Avoid

Hardcoding CRM IDs or access tokens in code; use secure vaults instead.
Over-fetching CRM data; implement precise data mappings and field selections.
Neglecting PDF rendering consistency across templates and locales.
Skipping validation on templates, leading to broken proposals.

Related Cursor rules templates

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

FAQ

What CRM integrations are supported?

The template enforces a CRM integration pattern that supports popular platforms via REST or OAuth 2.0, with pluggable connectors for Salesforce and HubSpot. Data sync is asynchronous where possible to avoid blocking proposal work.

Can templates be customized for different proposal types?

Yes. The configuration supports versioned templates with dynamic fields and a preview stage in the UI; templates can be exported to PDF after approval.

How are PDFs generated?

PDFs are rendered from HTML/CSS templates using a deterministic layout engine, ensuring consistent branding across templates and locales.

Is there an approval workflow?

Yes. Proposals flow through draft, review, and approve stages with audit timestamps and user IDs; changes require re-approval to maintain governance.

How is data secured and access controlled?

Secrets are stored in a vault, API access uses tokens with short lifespans, and all inputs are validated. Data at rest is encrypted and audits are enabled.

Target User

Use Cases