Cursor Rules Template for B2B Marketing Platform

Overview

Direct answer: This Cursor rules configuration provides a copyable, drop-in workflow for building a B2B account-based marketing platform with company enrichment, campaign tracking, and AI prospect research on a Python FastAPI + PostgreSQL stack with Cursor AI.

The configuration is designed to be pasted into a project root as a .cursorrules file and used by Cursor AI to evaluate code, enforce architecture, and guide development.

When to Use These Cursor Rules

• When starting a new B2B marketing platform with ABM capabilities and AI-assisted research.
• When you require a consistent backend architecture for lead enrichment, campaign tracking, and attribution.
• When you need enforceable code style, security, and testing patterns across the team.
• When you want repeatable, auditable AI guidance for FastAPI + PostgreSQL deployments.

Copyable .cursorrules Configuration

Paste this block into your project root as .cursorrules to apply the rules for Cursor AI on this stack.

# Cursor Rules Template for Python FastAPI + PostgreSQL
framework_role: "Backend Engineer for a B2B marketing platform (PostgreSQL, SQLAlchemy, FastAPI)"
framework_context: "You produce copyable, drop-in .cursorrules that enforce architecture, style, and security for a Python FastAPI + PostgreSQL stack enabling company enrichment, campaign tracking, and AI prospect research with Cursor AI."
code_style_guides: ["Black","ruff","mypy","isort"]
architecture_and_directories:
  - app/
  - app/api/
  - app/core/
  - app/db/
  - app/models/
  - app/services/
  - tests/
  - migrations/
authentication_and_security:
  auth: "OAuth2 with PKCE and JWT access tokens"
  encryption: "AES-256 at rest; TLS in transit"
  secret_management: "env vars, secret manager"
database_and_orm:
  orm: "SQLAlchemy"
  database: "PostgreSQL"
  migrations: "Alembic"
  patterns: ["Repository pattern","Unit of Work"]
testing_and_linting:
  tests: ["pytest","pytest-asyncio"]
  lint: ["ruff","black"]
  ci: "GitHub Actions: lint + tests on PR"
prohibited_actions:
  - "Do not perform external network calls from AI unless whitelisted by project policy"
  - "Do not embed plaintext secrets or credentials in code blocks"
  - "Do not modify production schemas without a migration plan"

Recommended Project Structure

project-root/
├── app/
│   ├── api/
│   │   ├── v1/
│   │   │   ├── endpoints.py
│   │   │   └── dependencies.py
│   ├── core/
│   │   ├── config.py
│   │   └── security.py
│   ├── models/
│   ├── services/
│   └── db/
├── tests/
├── migrations/
├── alembic.ini
├── pyproject.toml

Core Engineering Principles

• Explicit boundaries between API, business logic, and data access.
• Validate all inputs with pydantic models and type hints.
• Versioned database migrations and repeatable deployment steps.
• Treat secrets as sensitive data; never commit them.
• Defensive coding against common web risks (injection, CSRF, path traversal).
• Observability: structured logging, tracing, and metrics from the API layer.
• Cursor AI rules are opinionated but auditable and reproducible.
• Testability: unit, integration, and contract tests with CI checks.

Code Construction Rules

• Use FastAPI routers for endpoints; keep business logic in services.
• Use SQLAlchemy with a clear repository pattern and dependency injection.
• Prefer async DB sessions and proper transaction handling.
• Use pydantic models for request/response validation and serialization.
• Do not perform IO in request handlers beyond request/response lifecycle.
• Keep environment-specific values in configuration and access via dependencies.
• Lock down DNS lookups and avoid network calls in the AI evaluation path.
• Write tests that exercise the full stack: API, service, and database.

Security and Production Rules

• Enforce JWT + OAuth2, short-lived tokens, and refresh flows for API access.
• Harden secrets; fetch from a managed secret store; never hard-code.
• Prefer TLS everywhere; enable HTTP strict transport security (HSTS).
• Limit data exposure by scope-based access control and field-level encryption where appropriate.
• Protect user data with input validation and defensive coding against injections.
• Use feature flags and canary deployments for production risk management.

Testing Checklist

• Unit tests for services and models; integration tests for API endpoints.
• Database migrations tested in CI against a clean database state.
• Static analysis with lint and type checks; format with Black on pre-commit.
• End-to-end tests for ABM workflows using synthetic data.

Common Mistakes to Avoid

• Skipping migrations or performing schema changes ad-hoc in production.
• Overexposing data through APIs; missing field-level access control.
• Relying on global mutable state; avoid singletons across modules.
• Ignoring observability; failing to emit logs and metrics for critical paths.
• Hard-coding secrets in code blocks or configs shared in PRs.

Related Cursor rules templates

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

• Cursor Rules Template: Python FastAPI API Monitoring
• Quality Control Inspections Cursor Rules Template for a QC Platform
• Cursor Rules Template: Marketing Analytics Platform with Campaign Tracking, Attribution, Landing Page Analytics and AI Insights
• KPI Dashboard Builder — Cursor Rules Template for Cursor AI

FAQ

What is this Cursor Rules Template for?

A Cursor Rules Template is a copyable block of Cursor AI instructions that codifies engineering standards, architecture, and security for a Python FastAPI + PostgreSQL ABM stack.

Which stack does this template target?

This template targets a Python FastAPI + PostgreSQL stack using SQLAlchemy for ORM, Alembic for migrations, Pytest for testing, and Cursor AI for rules enforcement.

How do I apply the .cursorrules block?