Cursor Rules Template: Django Subscription Dashboards | Cursor Rules | Suhas Bhairav

Overview

The Cursor rules configuration for Django + PostgreSQL enables building usage-based retention dashboards for subscription businesses. This Cursor Rules Template provides a copyable .cursorrules block and stack-specific guidance so you can quickly wire event streams (signups, plan changes, activity, and churn signals) to dashboards that measure retention, churn risk, and ARPU. It also codifies safe AI-assisted analytics practices for data access and reporting.

When to Use These Cursor Rules

When you need a repeatable, auditable rule set for dashboards that rely on user-event streams.
When your stack is Django + PostgreSQL and you want a clear separation of analytics logic from core business logic.
When you require safe AI augmentation for dashboard generation, data access, and anomaly detection with Cursor AI.
When you want a portable configuration that can be pasted into a project root as .cursorrules alongside your codebase.

Copyable .cursorrules Configuration

# Cursor Rules: Django + PostgreSQL - Subscription Retention Dashboards
# Cursor Rules Template for Django projects
[Framework]
name = "Django"
version = "4.x"
runtime = "Python 3.11+"
stack = "PostgreSQL, Redis"

[Context]
role = "Cursor AI acts as a Django backend engineer focused on analytics dashboards for subscription platforms."
frameworkContext = "You collect and transform user events (signups, logins, plan changes, usage events) into retention metrics."

[CodeStyle]
style = "PEP8 | Black"
linters = "flake8, mypy"

[Architecture]
directories = "/subscriptions, /subscriptions/dashboards, /analytics, /config, /templates"
modularization = "apps: subscriptions, dashboards, analytics"

[Authentication & Security]
auth = "JWT with Django REST Framework; enforce per-endpoint auth; rotate tokens; audit logs"
secrets = "use environment vars; do not hardcode keys; enable vault/secret management in prod"

[Database & ORM]
orm = "Django ORM; use select_related/prefetch_related; index(event_time, user_id); avoid raw SQL where possible"
queries = "parameterized; avoid string concatenation; use ORM annotations for aggregates"

[Testing & Linting Workflows]
testing = "pytest-django; factory_boy; pytest-cov; flake8; mypy"
ci = "CI runs migrations, runs tests, and lints on push"

[ProhibitedActions & Anti-patterns]
doNot = "Do not bypass authentication; do not perform destructive migrations in CI; do not concatenate SQL strings; do not bypass rate limits when fetching analytics data"

Recommended Project Structure

myproject/
  manage.py
  myproject/
    __init__.py
    settings.py
    urls.py
    wsgi.py
  subscriptions/
    __init__.py
    models.py
    views.py
    urls.py
    dashboards/
      __init__.py
      views.py
      templates/
        dashboards/
          retention_dashboard.html
  analytics/
    __init__.py
    dashboards/
      dashboards_logic.py
  templates/
    base.html
  requirements.txt
  pytest.ini

Core Engineering Principles

Single source of truth for analytics rules; keep business logic separate from analytics rules.
Idempotent transformations on events; dashboards should be reproducible from the same event stream.
Defensive data access: enforce least privilege and data minimization in all queries.
Test-driven analytics: unit tests for serializers, dashboards calculations, and permissions.
Safe AI augmentation: Cursor AI should assist, not replace, explicit data access controls.

Code Construction Rules

Use Django ORM for all analytics reads; avoid ad-hoc raw SQL in dashboards unless absolutely necessary with parameterization.
Organize code into apps: subscriptions (core), analytics (dashboards), dashboards (UI and data access).
End-to-end data flow: events -> aggregates -> dashboards -> API endpoints for front-end queries.
Endpoints must validate inputs, paginate results, and apply field-level permissions for dashboards.
Adopt PEP8, Black formatting, and pytest-django test suites; lint before merging.
Do not hardcode secrets; retrieve from environment or secret manager in prod.

Security and Production Rules

Enable HTTPS; enforce CSRF protection on all user-facing endpoints.
Use signed tokens with short lifetimes and rotate refresh tokens regularly.
Audit trail for analytics access; restrict data exposure in dashboard APIs.
Limit query complexity for dashboards to prevent DoS via heavy aggregations.
Use proper database permissions and least-privilege DB roles for analytics users.

Testing Checklist

Unit tests for models and serializers; tests for dashboard aggregations.
Integration tests for event ingestion, enrichment, and dashboard rendering.
End-to-end tests simulating retention scenarios across cohorts.
CI checks: migrations, lint, type checks, and full test suite.

Common Mistakes to Avoid

Mixing business logic into views; keep analytics logic in dedicated modules.
Over-fetching data; always paginate and filter dashboard queries.
Ignoring data retention when designing dashboards; ensure long-term storage of event streams.
Skipping tests for dashboards; analytics correctness is critical for decision making.

FAQ

What is a Cursor Rules Template for Django subscription dashboards?

A Cursor Rules Template provides a copyable, stack-specific set of Cursor AI rules that guide how an analytics dashboard for Django + PostgreSQL should gather, transform, and present usage-based retention metrics. It includes a ready-to-paste .cursorrules block and implementation guidance to keep AI-assisted development safe and consistent.

Which parts of the Django stack does this template cover?

The template covers the Django ORM for analytics data, PostgreSQL for storage, Redis for caching, Django REST Framework for APIs, and a structured project layout focused on subscriptions and dashboards. It codifies how event streams map to retention metrics while constraining AI-assisted actions.

How do I integrate the .cursorrules file into my project?

Copy the .cursorrules block into a root-level file named .cursorrules in your Django project, then ensure your Cursor AI integration reads it for rules, prompts, and validations when handling analytics queries and dashboard generation.

What safety measures are included for Cursor AI in this template?

The template enforces per-endpoint authentication, data access restrictions, and explicit anti-patterns to prevent unsafe prompts, SQL injections, or data exfiltration. It also requires parameterized queries and validated inputs for all analytics calculations.

Can I adapt this for other SQL backends?

Yes, but you should adjust ORM usage and migrations patterns for the target database, ensure appropriate indexing, and revise any database-specific SQL usage to maintain performance and safety in analytics workloads.

What should I test first when implementing this template?

Start with unit tests for event ingestion and dashboard calculations, then integration tests for API endpoints, and finally end-to-end tests simulating real retention scenarios to verify dashboard correctness and performance.

Cursor Rules Template: Django Subscription Cursor Rules

Target User

Use Cases