Brainstorming

Advanced Brainstorming Protocol

Structured ideation and design for modern web products — 2026 stack guidance included.

How to Run a Brainstorming Session

Phase 1: Understand the Problem Space

Before generating solutions, extract clarity on:

1. What — What is being built? (feature, product, system)
2. Who — Target users / personas
3. Why — Core problem being solved / jobs to be done
4. Constraints — Budget, timeline, team size, existing stack
5. Success metrics — How will we know it worked?

Ask targeted questions. Do NOT generate solutions until you have at least 3–4 of these answers.

Phase 2: Explore Solution Space

Generate ideas across multiple dimensions:

Diverge (generate broadly)

• List 5–10 approaches without filtering
• Include unconventional or ambitious options
• Consider: simplest possible solution, most scalable, most user-delightful

Converge (evaluate & select)

Use a simple scoring matrix:

Score = Impact - (Effort × 0.5) - (Risk × 0.3)

Phase 3: Design Document Output

After convergence, produce a structured Design Document (DD):

Design Document Template

# [Feature/Product Name] — Design Document

**Version**: 1.0.0
**Date**: YYYY-MM-DD
**Author**: [Name]
**Status**: Draft | Review | Approved

---

## 1. Overview

### Problem Statement
[1–3 sentences describing the problem]

### Proposed Solution
[1–3 sentences describing what we're building]

### Goals
- [ ] Goal 1
- [ ] Goal 2

### Non-Goals
- NOT doing X
- NOT doing Y

---

## 2. User Stories

| ID | As a... | I want to... | So that... | Priority |
|----|---------|-------------|------------|----------|
| U1 | visitor | sign in with passkey | skip passwords | P0 |
| U2 | user | see AI-suggested content | discover faster | P1 |

---

## 3. Technical Architecture

### Stack Decision
| Layer | Choice | Reason |
|-------|--------|--------|
| Framework | Next.js 15 | App Router, RSC, PPR |
| Database | PostgreSQL + Drizzle | Type-safe, migrations |
| Auth | Clerk / Passkeys | WebAuthn, MFA |
| AI | Vercel AI SDK + Claude | Streaming, tool use |
| Cache | Redis (Upstash) | Serverless-safe |
| Deployment | Vercel | Zero-config, edge |

### System Diagram (describe components)

[Browser] │ HTTPS ▼ [Next.js Edge Middleware] ← auth check, geo, A/B │ ├── [RSC Pages] ← DB queries, no JS shipped │ └── [Client Components] ← interactive islands │ ├── [Server Actions] ← mutations, form handling │ └── [API Routes] ← webhooks, external integrations │ ├── [PostgreSQL] ← primary data ├── [Redis] ← cache, sessions, queues └── [BullMQ Workers] ← async jobs

### Data Models
```typescript
// Core entities
type User = {
  id: string
  email: string
  // ...
}

4. Feature Breakdown

[Feature 1 Name]

Description: [What it does] User flow: [Step by step] Technical notes: [How it works under the hood] Edge cases: [What can go wrong]

5. API Design

Endpoints

Server Actions

6. Security Considerations

• Input validation (Zod on all boundaries)
• Rate limiting on public endpoints
• CSRF protection (Server Actions have built-in protection)
• RLS policies on database
• Secrets in environment variables only
• Passkeys / MFA for sensitive operations

7. AI Integration (if applicable)

Model & SDK

• Use claude-sonnet-4-6 via Vercel AI SDK
• Streaming responses for UX responsiveness

// Example AI integration
import { streamText } from 'ai'
import { anthropic } from '@ai-sdk/anthropic'

export async function POST(request: Request) {
  const { messages } = await request.json()

  const result = await streamText({
    model: anthropic('claude-sonnet-4-6'),
    system: 'You are a helpful assistant.',
    messages,
    maxTokens: 1000,
  })

  return result.toDataStreamResponse()
}

AI Features Checklist

• Streaming responses (never block waiting for full response)
• Tool use / function calling (for structured outputs)
• Fallback for AI failures (degrade gracefully)
• Rate limiting per user
• Cost attribution per user/tenant

8. Passkeys / WebAuthn (if applicable)

Flow

1. Registration: User creates passkey bound to device + domain
2. Authentication: Browser signs challenge with private key; server verifies with stored public key
3. No passwords stored — only public keys in DB

Implementation

• Use @simplewebauthn/server + @simplewebauthn/browser
• Or Clerk (handles WebAuthn automatically)
• Store: { credentialId, publicKey, userId, deviceName, createdAt }

9. Partial Prerendering (PPR) Strategy

// next.config.ts
export default {
  experimental: {
    ppr: 'incremental', // opt-in per route
  },
}

// app/dashboard/page.tsx
export const experimental_ppr = true

// Static shell renders instantly at edge
export default function Dashboard() {
  return (
    <div>
      <StaticHeader />        {/* Prerendered — instant */}
      <Suspense fallback={<Skeleton />}>
        <DynamicFeed />       {/* Streams in after */}
      </Suspense>
      <Suspense fallback={<Skeleton />}>
        <PersonalizedSidebar /> {/* Streams in after */}
      </Suspense>
    </div>
  )
}

PPR Decision Guide:

• Use PPR when: page has mix of static shell + dynamic content
• Skip PPR when: entire page is dynamic (dashboard with user-specific data)
• Always use PPR when: marketing/product pages with personalization

10. Performance Targets

11. Milestones & Rollout

12. Open Questions

• Q: [Question needing answer]
  • Owner: [Name]
  • Due: [Date]

13. Alternatives Considered

---

## 2026 Modern Web Guidance Cheat Sheet

| Concern | Recommended Approach |
|---------|---------------------|
| **Rendering** | PPR (static shell + streaming dynamic) |
| **State** | Server state via RSC + `useOptimistic` for UI |
| **Mutations** | Server Actions + `useActionState` |
| **Auth** | Passkeys (WebAuthn) + Clerk |
| **AI** | Vercel AI SDK + streaming + tool use |
| **Data** | Drizzle ORM + PostgreSQL + Redis cache |
| **Search** | Postgres full-text or Typesense |
| **Files** | Vercel Blob or S3 |
| **Emails** | Resend + React Email |
| **Payments** | Stripe + webhooks via BullMQ |
| **Monitoring** | Sentry + Vercel Analytics |
| **Deployment** | Vercel (primary) or Fly.io (Docker) |

---

## Brainstorming Anti-Patterns to Avoid

❌ **Premature convergence** — Don't pick the first solution; explore at least 3  
❌ **Gold-plating** — Don't design for 10M users when you have 10  
❌ **Technology-first thinking** — Start with the problem, then pick tools  
❌ **Missing non-goals** — Explicitly state what you're NOT building  
❌ **No success metrics** — Every design doc needs measurable outcomes  
❌ **Skipping security section** — Auth, input validation, RLS always needed  
❌ **No fallback for AI** — AI calls can fail; always degrade gracefully