Best .cursorrules for Indian Projects: React, Next.js, Python

The .cursorrules file is the single most impactful configuration you can add to any Cursor project. It tells the AI exactly how your team writes code — your stack, patterns, naming conventions, and project-specific rules. Without it, Cursor makes educated guesses. With it, Cursor generates code that fits seamlessly into your codebase. This guide provides five tested, production-ready templates designed for the most common tech stacks used by Indian developers.

What You'll Learn

• What .cursorrules is and why it dramatically improves AI output
• How the rules system works (project root + .cursor/rules/)
• 5 complete, copy-paste templates for popular Indian tech stacks
• How to customize templates for your specific project
• Advanced rules for Indian-specific requirements
• Marketplace templates on PromptAndSkills

How .cursorrules Works

File Locations

Cursor reads rules from two locations:

your-project/
├── .cursorrules              ← Main project rules (read first)
├── .cursor/
│   └── rules/
│       ├── react.md          ← Topic-specific rules
│       ├── api.md            ← Applied based on context
│       └── database.md       ← Read when relevant files are open
├── src/
└── package.json

.cursorrules in the project root is always read for every AI interaction.

.cursor/rules/*.md files are contextual — Cursor reads them when they are relevant to the current task. For example, if you are editing a React component, it reads react.md but not database.md.

What to Include

A good .cursorrules file covers:

1. Tech stack — Frameworks, languages, versions
2. Project structure — Where different types of files live
3. Coding conventions — Naming, formatting, patterns
4. Anti-patterns — Things the AI should never do
5. Domain-specific rules — Business logic, data formats, compliance

Template 1: Next.js 15 + TypeScript + Tailwind

This is the most popular stack among Indian startups and indie developers in 2026.

You are an expert Next.js 15 developer building an Indian web application.

## Tech Stack
- Next.js 15 with App Router (NOT Pages Router)
- React 19 with Server Components by default
- TypeScript 5 with strict mode enabled
- Tailwind CSS 4 for all styling
- shadcn/ui for component primitives
- Prisma ORM with PostgreSQL
- NextAuth.js v5 for authentication
- Zod for runtime validation

## Project Structure
- app/ — App Router pages and layouts
- app/api/ — API route handlers
- components/ui/ — shadcn/ui primitives (Button, Card, Dialog, etc.)
- components/features/ — Domain-specific components (ProductCard, UserProfile)
- components/layout/ — Header, Footer, Sidebar, Navigation
- lib/ — Utility functions, API client, database queries
- lib/db/ — Prisma client and database query functions
- hooks/ — Custom React hooks
- types/ — TypeScript type definitions
- public/ — Static assets

## Coding Conventions

### Components
- Use Server Components by default
- Add 'use client' ONLY when using: useState, useEffect, onClick, onChange, or other client-side APIs
- Use named exports: `export function ProductCard()` NOT `export default function`
- Props interface above the component: `interface ProductCardProps { ... }`
- Destructure props in the function signature
- Use Tailwind CSS classes directly — no CSS modules, no styled-components

### TypeScript
- NEVER use `any` type — use `unknown` and narrow with type guards
- Define interfaces for all props, API responses, and data shapes
- Use Zod schemas for runtime validation of API inputs
- Prefer `type` for unions and intersections, `interface` for object shapes

### Data Fetching
- Server Components: use async/await with direct database calls or fetch
- Client Components: use React Query (TanStack Query) for data fetching
- API routes: return `NextResponse.json()` with proper status codes
- Error responses: `{ error: string, details?: string[] }`

### Styling
- Tailwind CSS only — no inline styles except for dynamic values
- Use `cn()` utility (from lib/utils) to merge conditional class names
- Dark mode: always include dark: variants
- Responsive: mobile-first (default styles for mobile, sm: md: lg: for larger)

### Indian-Specific
- Currency: Format as INR with Indian numbering system using Intl.NumberFormat('en-IN')
- Dates: DD/MM/YYYY format using Intl.DateTimeFormat('en-IN')
- Phone: Indian 10-digit validation, pattern: /^[6-9]\d{9}$/
- PIN code: 6-digit Indian postal code
- GST: 15-character GSTIN format when relevant
- UPI: Handle UPI ID format (name@bank)

## Anti-Patterns — NEVER Do These
- NEVER use Pages Router patterns (getServerSideProps, getStaticProps)
- NEVER use `'use client'` on components that only render static content
- NEVER import from `@/components/ui/` without checking the component exists
- NEVER use `<img>` tags — always use `<Image>` from next/image
- NEVER hardcode API URLs — use environment variables
- NEVER store secrets in client-side code
- NEVER use `console.log` in production code — use proper error handling

Template 2: React + Vite + TypeScript (Frontend Only)

For developers building SPAs and frontend projects.

You are an expert React developer building a modern single-page application.

## Tech Stack
- React 19 with Vite 6 as the build tool
- TypeScript 5 with strict mode
- Tailwind CSS 4 for styling
- React Router v7 for routing
- TanStack Query v5 for server state management
- Zustand for client state management
- Zod for validation
- Axios for HTTP requests

## Project Structure
- src/components/ui/ — Reusable primitives (Button, Input, Modal)
- src/components/features/ — Feature components (Dashboard, ProductList)
- src/components/layout/ — App shell (Header, Sidebar, Footer)
- src/pages/ — Route-level components
- src/hooks/ — Custom hooks (useAuth, useDebounce, useLocalStorage)
- src/stores/ — Zustand stores (authStore, cartStore)
- src/services/ — API service functions grouped by domain
- src/types/ — TypeScript interfaces and types
- src/utils/ — Helper functions (formatters, validators)
- src/assets/ — Images, icons, fonts

## Conventions

### Components
- Functional components only — no class components
- Named exports for all components
- One component per file, file name matches component name in PascalCase
- Props interface defined above the component
- Destructure props in the function parameter

### State Management
- Zustand for global client state (auth, theme, cart)
- TanStack Query for all server state (API data)
- useState for local component state
- NEVER use Redux — this project uses Zustand

### API Layer
- All API calls go through src/services/
- Each domain gets its own service file: userService.ts, productService.ts
- Use Axios interceptors for auth token injection and error handling
- Return typed data from service functions, not raw Axios responses

### Error Handling
- Wrap API calls in try/catch
- Display user-friendly error messages via toast notifications
- Log detailed errors to console in development only
- Show loading skeletons while data is being fetched

### Indian-Specific
- Currency: ₹ symbol with Indian number format (₹1,23,456)
- Date: DD/MM/YYYY using dayjs with Indian locale
- Phone validation: /^[6-9]\d{9}$/ for Indian mobile numbers
- State/city dropdowns: Include all Indian states and UTs
- Language: Support English as primary, prepare i18n structure for Hindi

## Anti-Patterns
- NEVER use any type — always define proper TypeScript types
- NEVER fetch data in useEffect directly — use TanStack Query
- NEVER mutate state directly — use Zustand's set() or immer middleware
- NEVER put business logic in components — extract to hooks or services
- NEVER use index as key in lists that can be reordered

Template 3: Python Django REST Framework

Popular in Indian enterprise development and startups.

You are an expert Python/Django developer building a REST API for an Indian application.

## Tech Stack
- Python 3.12
- Django 5.1 with Django REST Framework 3.15
- PostgreSQL 16 database
- Celery + Redis for background tasks
- Django Filter for query filtering
- drf-spectacular for OpenAPI documentation
- pytest + factory_boy for testing
- Docker for local development

## Project Structure
- config/ — Django settings, urls, wsgi, asgi
- apps/ — Django apps, each in its own directory
- apps/{name}/models.py — Database models
- apps/{name}/serializers.py — DRF serializers
- apps/{name}/views.py — DRF viewsets and views
- apps/{name}/urls.py — URL patterns
- apps/{name}/services.py — Business logic (NOT in views)
- apps/{name}/tasks.py — Celery background tasks
- apps/{name}/tests/ — Test files
- common/ — Shared utilities, base classes, mixins
- requirements/ — Separate requirements files (base, dev, prod)

## Conventions

### Models
- Every model inherits from TimeStampedModel (has created_at, updated_at)
- Use UUIDs for primary keys, not auto-increment integers
- Add db_index=True on fields used in WHERE clauses
- Use choices for enum-like fields with Django's TextChoices
- Soft delete using is_active=False, never hard delete user data
- Always add __str__ method returning a meaningful representation

### Views and Serializers
- Use ModelViewSet for standard CRUD resources
- Business logic goes in services.py, NOT in views or serializers
- Use separate serializers for create, update, list, and detail
- Pagination: cursor-based using CursorPagination, not PageNumberPagination
- Filter using django-filter with FilterSet classes
- Return consistent error format: {"error": "message", "details": [...]}

### API Design
- URL pattern: /api/v1/{resource}/ (plural nouns)
- Use action decorators for non-CRUD endpoints: @action(detail=True)
- Authentication: JWT via SimpleJWT (access: 15min, refresh: 30 days)
- Permissions: Use custom permission classes, not inline checks

### Indian-Specific
- Currency fields: Use DecimalField(max_digits=12, decimal_places=2) for INR
- Phone: CharField with Indian phone validation regex
- PAN: CharField with validation for XXXXX0000X format
- Aadhaar: CharField with 12-digit validation (store encrypted)
- GST: CharField with 15-character GSTIN validation
- Pincode: CharField with 6-digit Indian postal code validation
- Date format in serializers: DD/MM/YYYY using date_format='%d/%m/%Y'

### Code Style
- Follow PEP 8
- Use type hints for function parameters and return types
- Docstrings for all public functions and classes (Google style)
- Import order: stdlib, third-party, Django, local (enforced by isort)
- f-strings for string formatting, not .format() or %

## Anti-Patterns
- NEVER put business logic in views — use services.py
- NEVER use raw SQL unless absolutely necessary for performance
- NEVER return model instances from API views — always serialize
- NEVER store passwords in plain text — use Django's built-in hashing
- NEVER use print() — use Python logging module
- NEVER catch bare exceptions — always specify the exception type

Template 4: MERN Stack (MongoDB + Express + React + Node.js)

The most popular full-stack combination taught in Indian coding bootcamps.

You are an expert MERN stack developer building a web application for the Indian market.

## Tech Stack
- Node.js 22 with Express.js 5
- MongoDB with Mongoose ODM
- React 19 with Vite for the frontend
- TypeScript on both frontend and backend
- JWT for authentication
- Multer for file uploads
- Joi for request validation

## Project Structure
### Backend (server/)
- server/src/controllers/ — Route handlers (thin, delegate to services)
- server/src/services/ — Business logic
- server/src/models/ — Mongoose schemas and models
- server/src/routes/ — Express route definitions
- server/src/middleware/ — Auth, error handling, validation
- server/src/utils/ — Helper functions
- server/src/config/ — Database connection, environment variables
- server/src/types/ — TypeScript interfaces

### Frontend (client/)
- client/src/components/ — React components
- client/src/pages/ — Route-level pages
- client/src/hooks/ — Custom hooks
- client/src/services/ — API service layer
- client/src/stores/ — Zustand state management
- client/src/types/ — TypeScript types

## Conventions

### Backend
- Controllers handle HTTP only — extract params, call service, send response
- Services contain all business logic and database queries
- Models define Mongoose schemas with proper validation
- Use async/await everywhere — no callbacks, no .then() chains
- Global error handling middleware catches all unhandled errors
- Return consistent responses: { success: boolean, data?: any, error?: string }

### Mongoose Models
- Always include timestamps: true in schema options
- Add indexes on fields used in queries
- Use virtual fields for computed properties
- Validate at the schema level using Mongoose validators
- Reference documents with ObjectId and populate when needed

### Authentication
- JWT access token (15 minutes) stored in httpOnly cookie
- Refresh token (30 days) stored in httpOnly cookie
- Password hashing with bcryptjs (salt rounds: 12)
- Rate limiting on auth routes (5 attempts per 15 minutes)

### Frontend
- Follow the same React conventions as Template 2
- API base URL from VITE_API_URL environment variable
- Axios interceptors handle token refresh automatically
- React Router for routing, TanStack Query for server state

### Indian-Specific
- MongoDB stores amounts as Numbers with 2 decimal places
- Custom Mongoose validator for Indian phone: /^[6-9]\d{9}$/
- Date formatting helper: toIndianDate() returns DD/MM/YYYY
- Currency formatting helper: toINR() returns ₹1,23,456 format
- Aadhaar and PAN stored as encrypted strings using crypto module

## Anti-Patterns
- NEVER use mongoose.connect() without error handling
- NEVER store JWT secret in code — use environment variables
- NEVER return MongoDB _id directly — transform to id in responses
- NEVER skip input validation — validate all request bodies with Joi
- NEVER use callback pattern — always async/await
- NEVER expose stack traces in production error responses

Template 5: Flutter + Dart (Mobile Development)

For the growing Flutter developer community in India.

You are an expert Flutter developer building a mobile application for the Indian market.

## Tech Stack
- Flutter 3.27+ with Dart 3.6+
- State management: Riverpod 2.0
- Navigation: go_router
- HTTP: dio with interceptors
- Local storage: Hive
- Backend: Firebase (Firestore, Auth, Storage) or REST API
- Testing: flutter_test + integration_test

## Project Structure
- lib/core/ — App-wide config, theme, constants, utils
- lib/core/theme/ — App theme, colors, text styles
- lib/core/constants/ — API endpoints, asset paths, string constants
- lib/core/utils/ — Formatters, validators, helpers
- lib/features/ — Feature modules (each self-contained)
- lib/features/{name}/data/ — Models, repositories, data sources
- lib/features/{name}/presentation/ — Screens, widgets, controllers
- lib/features/{name}/providers/ — Riverpod providers
- lib/shared/widgets/ — Shared UI widgets used across features
- lib/routing/ — GoRouter configuration

## Conventions

### Architecture
- Feature-first folder structure — group by feature, not by type
- Each feature is self-contained with its own data, presentation, and providers
- Repository pattern: data sources → repository → provider → UI
- Riverpod for all state management — no setState() for complex state

### Widgets
- Extract widgets into separate files when they exceed 50 lines
- Use const constructors wherever possible for performance
- Name widgets descriptively: UserProfileCard, not Card1
- Prefer composition over inheritance for widget reuse

### State Management (Riverpod)
- Use Provider for simple values
- Use StateNotifierProvider for complex state with methods
- Use FutureProvider for async data loading
- Use StreamProvider for real-time data
- NEVER use ChangeNotifier — use StateNotifier

### Indian-Specific
- Support both English and Hindi with flutter_localizations
- Currency: ₹ symbol with Indian grouping (NumberFormat.currency(locale: 'en_IN'))
- Phone input: 10-digit with +91 prefix, use intl_phone_number_input package
- Date: DD/MM/YYYY using DateFormat('dd/MM/yyyy')
- UPI deep linking: upi://pay?pa=name@bank&pn=Name&am=100&cu=INR
- Support for Jio Phone and budget Android devices (min SDK 21)
- Test on 720x1280 and 1080x1920 screen sizes (most common in India)

### Performance
- Use const widgets to avoid unnecessary rebuilds
- Lazy load images with cached_network_image
- Pagination for all lists — never load all items at once
- Minimize widget tree depth — extract complex layouts

## Anti-Patterns
- NEVER use setState() for state shared across widgets — use Riverpod
- NEVER hardcode strings — use constants or localization
- NEVER skip null safety — handle all nullable types explicitly
- NEVER use print() — use debugPrint() or a logger
- NEVER block the main isolate with heavy computation — use compute()

Customizing Templates for Your Project

Step 1: Start with the Closest Template

Copy the template that matches your tech stack.

Step 2: Add Project-Specific Details

Add sections specific to your project:

## Business Domain
This is an e-commerce application for handmade Indian products.
- Products have: name, description, price (INR), images, artisan details,
  craft type (pottery, weaving, woodwork, etc.), and origin state
- Orders flow: Cart → Checkout → Payment (Razorpay) → Confirmation → Shipping
- Shipping partner integration via Delhivery API

## Database Schema Summary
- products: id, name, slug, price, artisan_id, craft_type, state, images[]
- orders: id, user_id, items[], total, status, payment_id, shipping_id
- artisans: id, name, craft, state, bio, verified

Step 3: Add Anti-Patterns from Your Experience

Over time, add rules based on mistakes you see:

## Learned Anti-Patterns
- NEVER use toFixed() for currency — use Intl.NumberFormat instead
- NEVER assume GST is always 18% — check the product category
- NEVER use new Date() without timezone — use IST (Asia/Kolkata)
- NEVER store prices as floating point — use integers (paise) and divide by 100

Sharing Rules Across Your Team

To ensure everyone on your team uses the same rules:

1. Commit .cursorrules and .cursor/rules/ to your Git repository
2. Include setup instructions in your README
3. Review and update rules during sprint retrospectives

For teams that also use Claude Code, maintain both .cursorrules and CLAUDE.md with consistent conventions. See our CLAUDE.md guide for the Claude Code equivalent.

Where to Go Next

• Cursor IDE complete tutorial — Set up Cursor and learn all features
• Cursor rules and project memory — Advanced rules configuration
• CLAUDE.md complete guide — The Claude Code equivalent of .cursorrules
• Cursor vs Copilot vs Claude Code — Choose the right AI coding tool
• Browse .cursorrules templates on the marketplace — Community-contributed templates

A well-crafted .cursorrules file is the difference between AI that generates generic code and AI that generates code your team actually wants. Start with these templates, customize for your project, and iterate as you discover new patterns. Within a week, you will wonder how you used Cursor without them.