Cursor Rules Template: Next.js + Supabase + Clerk + Resend + Shadcn UI for a HubSpot-lite Startup CRM
Cursor Rules Template for building a lightweight HubSpot-like CRM with Next.js, Supabase, Clerk, Resend, and Shadcn UI.
Target User
Developers building a startup CRM using Next.js, Supabase, Clerk, Resend, and Shadcn UI.
Use Cases
- Rapidly scaffold a HubSpot-like CRM for startups
- Define AI-driven guidance for frontend and backend tasks
- Enforce security policies with Clerk and Supabase RLS
- Recommend UI components using Shadcn UI
Markdown Template
Cursor Rules Template: Next.js + Supabase + Clerk + Resend + Shadcn UI for a HubSpot-lite Startup CRM
Framework Role & Context:
You are Cursor AI acting as a senior frontend/backend architect for a lightweight HubSpot-like CRM built with Next.js, Supabase, Clerk, Resend, and Shadcn UI. You optimize for rapid iteration and safe AI-assisted development.
Code Style and Style Guides:
- TypeScript-first
- ESLint + Prettier
- commit hooks and lint-staged
- Prefer composable components and clean types
Architecture & Directory Rules:
- Use Next.js 13+ app directory (app/)
- Project root structure:
apps/web/
apps/web/app/
apps/web/components/
apps/web/lib/
apps/web/services/
Authentication & Security Rules:
- Clerk for authentication; protect routes via middleware
- Use environment-based keys; never expose secrets to the browser
- Enforce role-based access control at the API boundary
Database and ORM patterns:
- Supabase Postgres with RLS; define roles for tenant owners
- Use supabase-js in server and client; avoid direct SQL strings in UI
- Do not bypass RLS or hard-code secrets
Testing & Linting Workflows:
- Vitest + Testing Library for unit tests
- Playwright or Cypress for end-to-end tests
- CI pipeline: lint, type-check, tests, and build
Prohibited Actions and Anti-patterns for the AI:
- Do not bypass authentication or authorization
- Do not embed API keys in client code
- Do not generate server logic that circumvents RLSOverview
Cursor rules configuration for building a lightweight HubSpot-like CRM for startups using Next.js, Supabase, Clerk, Resend, and Shadcn UI. This Cursor rules template is a copyable .cursorrules configuration you can paste into your project root to guide Cursor AI through architecture, security, and implementation details for this stack.
When to Use These Cursor Rules
- Starting a new startup CRM with Next.js, Supabase, Clerk, Resend, and Shadcn UI.
- Defining authentication, authorization, and multi-tenant access controls.
- Standardizing the project structure and coding style for rapid iteration.
- Enforcing security policies and data access at the API boundary and database layer.
- Guiding AI-assisted implementation of core CRM modules (contacts, companies, deals, activities).
Copyable .cursorrules Configuration
Framework Role & Context:
You are Cursor AI acting as a senior frontend/backend architect for a lightweight HubSpot-like CRM built with Next.js, Supabase, Clerk, Resend, and Shadcn UI. You optimize for rapid iteration and safe AI-assisted development.
Code Style and Style Guides:
- TypeScript-first
- ESLint + Prettier
- commit hooks and lint-staged
- Prefer composable components and clean types
Architecture & Directory Rules:
- Use Next.js 13+ app directory (app/)
- Project root structure:
apps/web/
apps/web/app/
apps/web/components/
apps/web/lib/
apps/web/services/
Authentication & Security Rules:
- Clerk for authentication; protect routes via middleware
- Use environment-based keys; never expose secrets to the browser
- Enforce role-based access control at the API boundary
Database and ORM patterns:
- Supabase Postgres with RLS; define roles for tenant owners
- Use supabase-js in server and client; avoid direct SQL strings in UI
- Do not bypass RLS or hard-code secrets
Testing & Linting Workflows:
- Vitest + Testing Library for unit tests
- Playwright or Cypress for end-to-end tests
- CI pipeline: lint, type-check, tests, and build
Prohibited Actions and Anti-patterns for the AI:
- Do not bypass authentication or authorization
- Do not embed API keys in client code
- Do not generate server logic that circumvents RLS
Recommended Project Structure
my-crm-lite/
├── apps/
│ └── web/
│ ├── app/
│ │ ├── layout.tsx
│ │ └── page.tsx
│ ├── components/
│ │ ├── ui/
│ │ │ ├── Button.tsx
│ │ │ └── Card.tsx
│ ├── lib/
│ │ ├── supabaseClient.ts
│ │ └── clerkClient.ts
│ └── services/
│ ├── email.ts
│ └── crm.ts
Core Engineering Principles
- Security-first design with explicit authentication and authorization boundaries.
- Type-safe, predictable code with TypeScript-first development.
- Clear separation of concerns across UI, domain, and data layers.
- Tenant isolation and data access policies via Supabase RLS.
- Automated testing and linting in CI to catch regressions early.
Code Construction Rules
- Use Next.js App Router with route handlers for server logic and client components for UI.
- Centralize Supabase client in lib, expose typed hooks for auth and data access.
- Enforce Clerk middleware for protected routes, and check user roles in API handlers.
- Employ Shadcn UI for consistent component styling; export reusable UI primitives.
- Respect the architecture decisions in the Cursor Rules Template to avoid drift.
- Do not embed secrets in the client; use environment variables and secret management.
Security and Production Rules
- Enable Supabase Row Level Security with tenant-based policies; test with realistic users.
- Store secrets securely and rotate keys; never commit secrets to VCS.
- Use HTTPS, secure cookies, and CSRF protection for API routes.
- Audit logs for authentication events and sensitive operations.
- Implement rate limiting and abuse detection for public endpoints.
Testing Checklist
- Unit tests for data access helpers and UI components.
- Integration tests for auth flows (Clerk) and API endpoints (Next.js route handlers).
- End-to-end tests simulating core CRM workflows (contacts, deals, activities).
- CI pipeline runs lint, type checks, tests, and production build.
Common Mistakes to Avoid
- Bypassing RLS or performing client-side authorization checks only.
- Storing secrets in client code or public repositories.
- Mixing server and client responsibilities in similar modules, causing SSR inconsistencies.
- Over-reliance on UI-only validation without server-side validation.
Related Cursor rules templates
Explore adjacent Cursor rules templates for similar stacks, workflows, and production constraints.
- Next.js SaaS Cursor Rules Template
- Cursor Rules Template: SaaS Revenue Dashboard (MRR, ARR, Churn & Cohorts)
- Cursor Rules Template: NestJS + Next.js + PostgreSQL for B2B Wholesale Portal
- Cursor Rules Template: LMS with Courses, Lessons, Quizzes, Certificates, Payments, and Admin Dashboard
FAQ
What is Cursor Rules Template for this stack?
This Cursor Rules Template provides a copyable .cursorrules configuration tailored to Next.js + Supabase + Clerk + Resend + Shadcn UI, guiding AI-assisted development of a HubSpot-like lightweight CRM for startups.
How do I use the copyable .cursorrules block?
Paste the block into your project root as .cursorrules. Cursor AI will parse the sections to guide code generation, enforcement of security rules, and directory structure for the stack.
Does this template enforce security and RLS policies?
Yes. The template defines authentication with Clerk, guards API routes with middleware, and describes enabling Row Level Security policies in Supabase to protect tenant data and enforce access controls across the CRM.
What tests should I implement for this stack?
Unit tests with Vitest and Testing Library, integration tests for auth flows and API endpoints, and end-to-end tests with Playwright or Cypress. Integrate into CI alongside linting and type checks.
Can I adapt this for production deployment?
Yes, but follow secure deployment practices, manage secrets securely, enable monitoring, and plan for scaling and observability. Start small and iterate with Cursor AI guidance.