MERN Stack AI Prompts: Build MongoDB, Express, React & Node.js Faster in 2026

You are a senior MERN stack architect who has built and scaled SaaS products to 1M+ users.

Design a production-grade monorepo structure for a multi-tenant MERN SaaS with:
- Express 5 + TypeScript API with REST and WebSocket support
- React 19 + Vite frontend, Zustand for global state
- MongoDB + Mongoose 8, multi-tenant with soft deletes and audit logging
- Redis for sessions, rate limiting, and Bull job queues
- Role-based access control: super_admin, org_admin, manager, member

Deliver:
1. Full directory tree (client/, server/, shared/ packages)
2. Module boundary decisions with one-sentence reasoning for each
3. Shared TypeScript types strategy (where they live, how they are imported)
4. .env.example with every required variable and a comment for each
5. The top 3 architectural trade-offs you considered and why you chose this pattern over the alternatives

You are a MongoDB expert who has designed schemas for applications with 50M+ documents and 10K+ requests per second.

Design Mongoose 8 TypeScript schemas for a project management app: Organization, User, Project, Task, Comment.

Requirements:
- Tenant isolation: tenantId indexed on every document
- Soft deletes: isDeleted (boolean) + deletedAt (Date) on all entities
- Audit trail: createdBy, updatedBy (ObjectId refs), createdAt, updatedAt (timestamps)
- Justify every reference vs embed decision with the query pattern that drove it
- Compound indexes for these access patterns:
  * All tasks for a project sorted by dueDate (most frequent query)
  * Overdue tasks for an organization filtered by assignee
  * Full-text search on task title and description
  * User activity feed (tasks created or updated in last 7 days)
- Virtuals: User.fullName, Task.isOverdue, Task.completionPercentage

Output: TypeScript Mongoose schemas, index definitions using index() chaining, and a two-sentence justification for each reference vs embed decision.

You are a MongoDB aggregation expert.

Write a Mongoose aggregate() pipeline for a real-time dashboard that computes for a given organizationId:
- Task completion rate per user for the last 30 days (top 10 by completion count)
- Average task completion time in hours per project
- Overdue task count grouped by priority (low / medium / high / critical)
- Week-over-week completion trend for the last 8 weeks (ISO week grouping)

Collection: tasks
Key fields: status (todo/in_progress/done/cancelled), assignedTo (ObjectId), completedAt (Date),
createdAt (Date), dueDate (Date), priority (String), projectId (ObjectId), organizationId (ObjectId)

Provide:
1. The complete aggregate() call with TypeScript result types using generics
2. A comment above each pipeline stage explaining what it does and why
3. Which indexes this pipeline requires to avoid COLLSCAN
4. Estimated memory usage if the pipeline processes 500,000 matching documents

You are a senior Express.js engineer building production APIs for high-scale SaaS products.

Generate a complete TypeScript Express 5 controller for a Task resource:

Endpoints: GET /tasks (paginated, filterable), GET /tasks/:id, POST /tasks, PUT /tasks/:id, DELETE /tasks/:id (soft delete)

Every endpoint must include:
- Zod validation schemas (request body, query params, route params)
- authenticate middleware: verify JWT, attach req.user with role and tenantId
- authorize middleware factory: requirePermission('tasks:write')
- Tenant-scoped queries: always filter by req.user.tenantId
- Optimistic concurrency on PUT: check version field, return 409 on conflict
- Structured responses: { success, data?, pagination?, message, code? }
- Async error propagation to global error handler (express-async-errors)
- Request ID propagation: read x-request-id header, attach to all log lines
- Response time logging: warn if endpoint exceeds 200ms

Output: router file, controller, Zod schemas, middleware references. TypeScript throughout.

You are a Node.js security engineer.

Build a production-grade Express 5 middleware stack in TypeScript. Implement in this exact order with explanation for why order matters:

1. Helmet: strict CSP, HSTS max-age=31536000, X-Frame-Options DENY
2. CORS: allowlist from CORS_ORIGINS env var (comma-separated), credentials: true
3. Rate limiting: 100 req/min per IP, Redis-backed (ioredis), return 429 with Retry-After header
4. Request ID: generate UUID v4, attach to req.id and set X-Request-ID response header
5. Structured logging: pino with JSON format, include request ID, method, path, status, duration
6. Body parser: JSON with 10kb size limit, reject oversized bodies with 413
7. Compression: gzip/brotli based on Accept-Encoding, threshold 1KB
8. JWT authentication: attach to specific route groups (not global), skip /health and /auth/login
9. Global error handler: log with request ID, return structured JSON, never leak stack trace in production

Output: app.ts setup file with all middleware. Add a comment on each line explaining the security or performance reason for its position in the stack.

You are a security engineer specializing in stateless authentication for Node.js APIs.

Implement a complete JWT auth system for Express 5:

Access tokens:
- RS256 (asymmetric — private key signs, public key verifies; keys loaded from env)
- 15-minute expiry
- Payload: { sub: userId, role, tenantId, iat, exp }

Refresh tokens:
- Stored in Redis with key: refresh:{userId}:{tokenFamily}
- 7-day expiry, delivered via httpOnly + Secure + SameSite=Strict cookie
- Token family tracking: each refresh generates new family ID
- Reuse detection: if a used token is presented again, invalidate the entire family, log a security event

Endpoints:
- POST /auth/login: bcrypt compare (timing-safe), issue both tokens
- POST /auth/refresh: validate Redis entry, rotate token, issue new pair
- POST /auth/logout: delete Redis entry, clear cookie
- Rate limit: 5 auth attempts per 15 minutes per IP

Output: TypeScript auth router, JWT utilities, Redis token service, and auth middleware. Add a security comment explaining each design decision.

You are an authorization systems architect.

Build a dynamic RBAC middleware system for Express with:
- Roles: super_admin, org_admin, manager, member, viewer
- Permission matrix: tasks:read, tasks:write, tasks:delete, projects:manage, org:manage, billing:manage
- Permission inheritance: super_admin inherits all; org_admin inherits manager's permissions; viewer is read-only
- Multi-tenant scoping: a user can be org_admin in Organization A but member in Organization B
- Middleware factory: requirePermission('tasks:write') — returns Express middleware
- Permission check utility: hasPermission(user, resource, action, tenantId): boolean
- Redis caching for permission lookups: TTL 5 minutes, auto-invalidate on role change
- Audit logging: log every permission denial with user ID, resource, action, tenantId, timestamp

TypeScript. Output: permission matrix object, middleware factory, Redis cache layer, and 5 usage examples showing different permission scenarios.

You are a senior React engineer specializing in performant, accessible UI components.

Build a DataTable<T extends Record<string, unknown>> React component with TypeScript generics for a MERN admin panel:

Required features:
- Virtual scrolling for 50,000+ rows using @tanstack/react-virtual
- Multi-column sorting with direction indicators (client-side and server-side modes via prop)
- Row selection: checkbox per row, shift+click range, select-all on current page
- Column resizing via drag handle
- Per-column filters (text, date range, enum select based on column type)
- Pagination: client-side and server-side modes
- Row action menu via renderRowActions prop (receives row data, returns ReactNode)
- States: loading skeleton (animated), empty state, error state with retry button
- WCAG 2.1 AA: keyboard navigation (arrow keys, Enter to select), ARIA grid role, screen reader announcements on sort/select

TypeScript interfaces required for: ColumnDef<T>, SortState, FilterState, PaginationState, SelectionState.
CSS Modules for styling. Zero external UI library dependencies.

You are a React hooks architect.

Build a production-ready useFetch<T> hook:

interface UseFetchOptions {
  deduplicate?: boolean;      // prevent concurrent identical requests (default: true)
  ttl?: number;               // cache TTL in ms (default: 30000)
  retries?: number;           // automatic retry count (default: 3)
  retryDelay?: number;        // base delay for exponential backoff in ms (default: 1000)
  onError?: (err: Error) => void;
}

Requirements:
- Request deduplication: same URL + body = single in-flight request (Map-based)
- SWR-style in-memory cache with TTL and stale-while-revalidate behaviour
- AbortController cancellation on component unmount or URL change
- Exponential backoff retry: 1s, 2s, 4s with jitter
- States: { data, loading, error, stale, refetch, mutate }
- mutate(): optimistic update + background revalidation on POST/PUT/DELETE
- TypeScript strict mode: no any types

Include: hook implementation, TypeScript types, and 4 usage examples (GET with pagination, POST with optimistic update, polling with interval, conditional fetch).

You are a React state management expert.

Design a Zustand store architecture for a MERN project management app. Create these stores:

authStore: user object, access token (in memory, never localStorage), auto-refresh logic (intercept 401, call /auth/refresh, retry original request), logout (clear all stores)
projectStore: CRUD operations, optimistic updates with rollback on failure, real-time sync via Socket.io events
taskStore: paginated task lists, active filters, sort state, bulk operations (assign, update status, delete)
uiStore: modal registry (open/close by ID), toast queue (max 5 visible), sidebar collapsed state, theme (light/dark)

Requirements:
- Persist authStore and uiStore to sessionStorage (not localStorage for auth tokens)
- Immer middleware for immutable state updates
- Redux DevTools middleware in development
- Selector hooks to prevent unnecessary re-renders: useTasksByProject(projectId)
- Action naming: verb + noun (fetchTasks, updateTask, clearFilters)

Output: full TypeScript store files, middleware configuration, and 3 selector hook examples.

You are a test engineering expert for Node.js MERN applications.

Write comprehensive Jest unit tests for this Express service function:

[PASTE SERVICE FUNCTION CODE HERE]

Cover every branch:
- Happy path for each operation
- Zod validation failures (missing fields, wrong types, business rule violations)
- Unauthorized access (missing JWT, expired JWT, wrong role)
- Tenant boundary violations (accessing another tenant's data)
- MongoDB errors: validation error, duplicate key (11000), connection timeout
- Redis errors: cache miss (handled gracefully), Redis connection failure (graceful degradation)
- Rate limit exceeded

Requirements:
- Mock all external dependencies: Mongoose models, ioredis, nodemailer, external APIs
- jest.spyOn for side effects: email sends, audit log writes, Socket.io emissions
- Assert on response shape, HTTP status code, and response headers
- AAA pattern: Arrange, Act, Assert with labeled comments
- Factory functions for test data (no hardcoded magic values)
- Target: 100% branch coverage — show coverage report format in a top comment

You are a DevOps engineer building CI/CD pipelines for MERN production applications.

Generate a complete GitHub Actions workflow for a MERN monorepo:

lint-and-test job (triggers on all PRs and main push):
- Node 22, pnpm with cache
- TypeScript compile check: tsc --noEmit on both client and server
- ESLint + Prettier check (fail on warnings)
- Server: Jest unit + integration tests, coverage gate 80%, upload to Codecov
- Client: Vitest unit tests + Playwright E2E against local server (docker-compose up)

security job (parallel to lint-and-test):
- npm audit --audit-level=high (fail build on high+ vulnerabilities)
- Trivy container scan on Dockerfile
- CodeQL analysis for JavaScript/TypeScript

docker job (main branch only, after lint-and-test passes):
- Multi-stage build: builder (tsc compile) + production (node:22-alpine, non-root user)
- Push to AWS ECR: tag with git SHA and 'latest'
- Image size check: fail if production image exceeds 200MB

deploy job (after docker job):
- Backend: AWS ECS rolling update via AWS CLI (zero-downtime)
- Frontend: Vercel CLI deploy
- Smoke test: curl /api/health, assert HTTP 200 and { status: 'ok' }
- Slack notification on success or failure with deploy URL

Include secrets management pattern and required GitHub repository secrets list.

You are a MongoDB performance engineer who has optimized queries on collections with 100M+ documents.

This aggregation pipeline runs in 4,200ms on a collection with 8M documents. Here is the current pipeline and indexes:

[PASTE PIPELINE + INDEXES HERE]

Diagnose and fix:
1. Run an EXPLAIN — identify whether it is COLLSCAN or IXSCAN and why
2. Recommend the optimal compound index (specify field order and direction with reasoning)
3. Rewrite any pipeline stages that block before the $match (push $match as early as possible)
4. Identify stages that can use $lookup with pipeline to filter before joining
5. Assess whether this result should be pre-computed in a separate summary collection (materialized view pattern)
6. Estimate query time after optimization

Context: 70% read workload, this query runs 80,000 times per day during business hours.

You are a DevOps engineer building production Docker images for Node.js APIs.

Write an optimized multi-stage Dockerfile for an Express 5 + TypeScript API:

Stage 1 (deps): install production + dev dependencies
Stage 2 (build): run tsc, output to dist/
Stage 3 (production):
- Base: node:22-alpine (not full Debian)
- Copy: dist/, node_modules (production only, re-installed from package.json)
- Non-root user: create 'appuser' (UID 1001), chown app directory, USER appuser
- EXPOSE the port from PORT env variable
- Health check: GET /health every 30s, 3 retries, 10s start period
- CMD: ["node", "dist/server.js"]
- No secrets, no .env files, no source code in final stage

After the Dockerfile:
1. A .dockerignore file
2. A docker-compose.yml for local development with MongoDB, Redis, and the API (volume mounts for hot-reload, depends_on with healthcheck conditions)
3. Three sentences explaining why multi-stage + non-root matters for production security

You are a Node.js real-time systems engineer.

Add Socket.io v4 to an existing Express 5 + TypeScript MERN app for collaborative task editing:

Authentication: verify JWT on connection using socket.use() middleware — reject unauthenticated connections with socket.disconnect()
Room strategy: one room per projectId (join on 'join-project' event, leave on disconnect)
Events to implement:
  - task:updated — broadcast to room when any user updates a task (include updatedBy and timestamp)
  - task:locked — optimistic lock when user starts editing (payload: taskId, lockedBy, expiresAt)
  - task:unlocked — release lock on save or 30s timeout
  - user:typing — debounced typing indicator (suppress if same user, broadcast to others in room)
  - connection:error — typed error events with code and message

Deliver:
1. Socket.io server setup integrated with existing Express app (shared HTTP server)
2. Auth middleware with JWT verify and req.user attachment
3. All event handlers with TypeScript event map types
4. React hook: useProjectSocket(projectId) — manages connect/disconnect lifecycle, exposes event emitters and listeners
5. Redis adapter setup (socket.io-redis) for horizontal scaling

You are a senior Node.js payments engineer with Stripe expertise.

Implement a Stripe subscription integration for an Express 5 TypeScript MERN SaaS:

Plans: starter ($29/mo), pro ($99/mo), enterprise (contact sales)
Implement:
1. POST /billing/create-checkout-session — Stripe Checkout with success_url and cancel_url, metadata: { userId, planId }
2. POST /billing/webhook — verify Stripe-Signature header (stripe.webhooks.constructEvent), handle: checkout.session.completed, customer.subscription.updated, customer.subscription.deleted, invoice.payment_failed
3. MongoDB subscription schema: customerId, subscriptionId, status, planId, currentPeriodEnd, cancelAtPeriodEnd
4. Middleware: requireActiveSubscription — check subscription.status === 'active' and currentPeriodEnd > now()
5. Webhook idempotency: store processed event IDs in Redis (TTL 24h), skip duplicates

Security requirements:
- Never log Stripe webhook raw body after signature verification
- Store only customerId and subscriptionId in MongoDB, not payment method details
- Webhook endpoint must be excluded from CSRF middleware

Output: router, webhook handler, MongoDB schema, and billing middleware. TypeScript throughout.

You are a Node.js backend engineer specializing in file handling and cloud storage.

Build a production-grade file upload system for a MERN app:

Stack: multer (memory storage, never disk), @aws-sdk/client-s3 v3, sharp for image processing

Requirements:
- POST /uploads: accept multipart/form-data, max 10MB, allowed MIME types: image/jpeg, image/png, image/webp, application/pdf
- Validation: check Content-Type header AND magic bytes (first 4 bytes) — not just file extension
- Images: resize to max 1920px width with sharp, preserve aspect ratio, strip EXIF metadata (privacy)
- Generate S3 key: uploads/{tenantId}/{year}/{month}/{uuid}.{ext} — never use user-supplied filenames
- S3 upload: Server-Side Encryption (SSE-S3), private ACL (no public URLs), signed URLs for access (1-hour expiry)
- MongoDB: store only the S3 key + metadata (size, mimeType, uploadedBy, tenantId) — not the signed URL
- Rate limit: 20 uploads per user per hour
- Cleanup: if MongoDB save fails after S3 upload, delete the S3 object (compensating transaction)

Output: upload router, S3 service, image processor, and FileUpload Mongoose schema. TypeScript.

You are a Node.js infrastructure engineer.

Build a production email queue system for an Express TypeScript MERN app:

Queue: BullMQ (not legacy Bull) with Redis, queue name: 'email'
Job types: welcome, password-reset, task-assigned, weekly-digest, invoice

For each job type:
- TypeScript interface for job data (no loose objects)
- Rate limit: 100 emails/hour per tenant, 10 password-reset per hour per email (anti-spam)
- Retry strategy: 3 attempts, exponential backoff (30s, 2min, 10min), dead-letter queue after 3 failures
- Priority: password-reset = high (1), welcome = normal (5), weekly-digest = low (10)

Worker:
- Nodemailer with SMTP transport (credentials from env), TLS required
- HTML templates with Handlebars (no inline styles — use inlined CSS via juice)
- Track sends in MongoDB: EmailLog { jobId, recipient, type, status, sentAt, error? }
- Concurrency: 5 workers, graceful shutdown (drain queue before process exit)

Output: queue setup, worker, email service interface, and example usage for each job type.

You are a search systems engineer.

Implement full-text search for a MERN task management app using MongoDB Atlas Search:

Index definition (Atlas Search, not legacy text indexes):
- Collection: tasks
- Fields: title (analyzed), description (analyzed), tags (keyword), assignedTo.name (analyzed)
- Custom analyzer: lowercase, stop words removed, edge n-gram for prefix matching

Search endpoint: GET /tasks/search?q=&filters=&page=&limit=
- Autocomplete: match title as user types (edge n-gram, debounced 300ms on client)
- Filters: status, priority, assignedTo (ObjectId), dueDate range — combine with compound query
- Relevance scoring: boost title matches over description, boost recently updated documents
- Pagination: cursor-based (not skip/limit — inconsistent on live data), return searchAfter cursor
- Tenant scoping: pre-filter by tenantId using filter clause (not must — preserves score)

Output: Atlas Search index definition JSON, Mongoose aggregate pipeline for search, React useSearch hook with debounce, and the compound query structure for combined search + filters.

I have an existing Express 5 JavaScript file that I need to convert to strict TypeScript. Here is the file:

[PASTE FILE HERE]

Requirements:
- TypeScript strict mode (strict: true in tsconfig — no exceptions)
- No 'any' types — infer or define explicit interfaces for everything
- Define interfaces for: request body shapes, query parameter shapes, response objects, database documents
- For Mongoose models: use the generic Model<IDocument> pattern with discriminator keys where applicable
- Preserve all existing behavior exactly — do not fix bugs or add features
- Add JSDoc comments only where the type alone doesn't convey intent (e.g. non-obvious business rules)
- After the converted file, list every type you created and whether it should live in a shared types package

Output: the converted TypeScript file, followed by a list of any assumptions you made about types that I should verify.

You are a Node.js performance engineer specializing in memory leak diagnosis.

My Express 5 Node.js API (running on Node 22) shows steadily increasing heap usage under load — memory climbs from 150MB to 800MB over 6 hours then OOMs. I have attached:

1. Heap snapshot 1 (taken at startup after warmup): [DESCRIBE OR PASTE SUMMARY]
2. Heap snapshot 2 (taken 4 hours in): [DESCRIBE OR PASTE SUMMARY]
3. The most-called route handler: [PASTE ROUTE CODE]
4. My middleware stack order: [LIST MIDDLEWARE]

Diagnose:
1. What memory category is growing? (strings, arrays, closures, event listeners, Buffers)
2. What is the most likely root cause given the code? List your top 3 suspects in order.
3. For each suspect: what specific heap snapshot comparison evidence would confirm it?
4. Write a targeted fix for the most likely cause
5. What process.memoryUsage() logging should I add to confirm the fix worked in production?

You are a technical documentation engineer.

Generate a complete OpenAPI 3.1.0 specification for this Express 5 TypeScript router:

[PASTE ROUTER FILE HERE]

Requirements:
- Extract every route, HTTP method, path parameter, query parameter, and request body
- Generate response schemas from the Zod validation schemas in the file (or infer from code)
- Authentication: Bearer token (JWT) using securitySchemes, mark every protected route
- Include: 200 success response, 400 validation error (with Zod error shape), 401 unauthorized, 403 forbidden, 404 not found, 429 rate limited, 500 server error
- Examples: include at least one request/response example per endpoint
- Servers: development (http://localhost:3001), production (https://api.{your-domain}.com)
- Tags: group endpoints by resource name

Output: complete OpenAPI 3.1.0 YAML. After the YAML, list any assumptions you made about undocumented behavior.

You are a platform engineer specializing in Node.js observability.

Add OpenTelemetry distributed tracing to an Express 5 TypeScript API:

SDK: @opentelemetry/sdk-node, @opentelemetry/auto-instrumentations-node
Exporter: OTLP/HTTP to a Grafana Tempo endpoint (URL from env OTEL_EXPORTER_OTLP_ENDPOINT)

Instrument:
- All HTTP requests: method, route (not raw path — use route pattern to avoid cardinality explosion), status, duration
- All Mongoose operations: collection name, operation type, duration — exclude query text (contains PII risk)
- All Redis operations: command name, duration, key prefix (not full key)
- Custom spans: wrap any function over 50ms with a named span
- Error recording: attach exception to span on any caught Error, set span status to ERROR

Custom attributes on every span:
- tenant.id, user.id (from authenticated request context — use AsyncLocalStorage to propagate)
- deployment.environment (from NODE_ENV)
- service.version (from package.json version)

Output: tracer setup file, instrumentation bootstrap (loaded before any other imports), middleware that attaches trace ID to response as X-Trace-ID header, and example of wrapping a Mongoose service method with a custom span.

You are a React performance engineer.

Audit this React component for performance issues and fix them:

[PASTE COMPONENT CODE HERE]

Check and fix each of these categories:
1. Unnecessary re-renders: identify which state/prop changes cause the component to re-render when they shouldn't — add React.memo, useMemo, useCallback where warranted (with justification for each, not blindly)
2. useEffect dependencies: find any missing or over-specified dependencies — fix the array, don't add eslint-disable comments
3. Expensive computations in render: identify calculations that should be memoized
4. Stale closures: find any event handlers or callbacks that capture stale state
5. Large list rendering: if this renders more than 50 items, recommend windowing (@tanstack/react-virtual)
6. Bundle impact: identify any imports that should be lazy-loaded or code-split

For each issue: show the problematic code, explain why it is a problem, and show the fixed version.

You are a test infrastructure engineer.

Build a type-safe test data factory system for a MERN TypeScript project:

Requirements:
- Factory pattern: createUser(overrides?), createOrganization(overrides?), createProject(overrides?), createTask(overrides?)
- Each factory: generates valid MongoDB ObjectIds, realistic fake data (faker-js), satisfies all Mongoose schema validators
- Override merging: deep merge, so createTask({ status: 'done', assignedTo: userId }) only overrides those fields
- Relationship factories: createProjectWithTasks(taskCount, overrides?) — creates project + N tasks with correct references
- Seed script: seeds a local MongoDB with 5 organizations, 20 users per org, 10 projects per org, 50 tasks per project — runnable with 'pnpm seed'
- Reset helper: clearDatabase() — drops all collections, usable in beforeEach for integration tests
- TypeScript: factory return types match the Mongoose document interfaces exactly — no casting

Output: factory file, seed script, and 3 example usages in Jest integration test context.

Context for all MERN prompts in this session:
- React 19 + Vite 6 (frontend)
- Express 5 + Node.js 22 LTS (backend)
- Mongoose 8 + MongoDB 8 (database)
- TypeScript 5.4, strict mode, ESM throughout
- Auth: JWT (RS256), access token 15min, refresh token in Redis (7 days)
- State: Zustand 5 + TanStack Query v5
- Testing: Vitest + React Testing Library (frontend), Supertest + mongodb-memory-server (backend)

Never generate:
- CommonJS require() — always ESM import/export
- React class components or lifecycle methods
- var declarations — use const/let
- mongoose.connect() inside route files (only in app startup)
- Synchronous file operations (always async/await)