Development pipeline with Windsurf
📋
PLANNING
SWE-1.6 → Sonnet 4.6
Requirements & architecture
⚡
IMPLEMENTATION
SWE-1.6 (free)
Feature development
🧪
TESTING
SWE-1.6 → Haiku 4.5
Test generation & validation
🔍
DEBUGGING
SWE-1.6 → Sonnet Thinking
Bug investigation & fixes
🚀
DEPLOYMENT
SWE-1.6 → Gemini 3.1 Pro
CI/CD & production
What I do: Before writing any code, I use Windsurf to break down requirements, discuss architecture decisions, and create implementation roadmaps. This saves hours of rework later.
Real-world example: When I was implementing real-time collaborative editing for our document editor, I fed Windsurf the PRD and asked it to generate a complete technical specification. It identified edge cases I hadn't considered — like conflict resolution when two users edit the same paragraph simultaneously, and how to handle offline sync.
My workflow: I start by giving Windsurf the PRD or feature requirements and ask: "Generate a technical spec with API contracts, database schema changes, and edge cases." Then I review, iterate, and only then move to implementation.
Model strategy: SWE-1.6 for initial task breakdown and feature scoping. For complex architecture discussions or system design decisions, I escalate to Claude Sonnet 4.6 Thinking — the reasoning depth is worth the quota cost here. For example, when deciding between WebSocket vs Server-Sent Events for real-time features, Sonnet's thinking mode walked me through the trade-offs and helped me choose the right approach.
Best practice: Keep planning sessions focused. Don't burn Opus quota on planning — SWE-1.6 handles 90% of planning tasks perfectly for free. Only escalate when you genuinely need deep reasoning.
📊 My Planning Workflow
┌─────────────┐
│ PRD / │
│ Requirements │
└──────┬──────┘
│
▼
┌─────────────┐ SWE-1.6 (Free)
│ Technical │ ───────────────► Generate spec
│ Spec │ with API contracts,
└──────┬──────┘ schema changes,
│ edge cases
▼
┌─────────────┐
│ Architecture │ ◄───── Sonnet 4.6 Thinking
│ Decisions │ (for complex trade-offs)
└──────┬──────┘
│
▼
┌─────────────┐
│Implementation│
│ Plan │
└─────────────┘
🏗️ Architecture Decision Example: Real-Time Sync
Client A WebSocket Server Client B
│ │ │
│──── edit ─────────────►│ │
│ │──── edit ─────────────►│
│ │ │
│◄──── ack ──────────────│ │
│ │◄──── ack ─────────────│
│ │ │
│◄──── conflict ─────────│◄──── conflict ────────│
│ resolution │ resolution │
Trade-offs evaluated by Windsurf:
• WebSocket vs SSE → Chose WebSocket (bidirectional needed)
• Operational Transform vs CRDT → Chose OT (simpler for our use case)
• Conflict resolution strategy → Last-write-wins with versioning
What I do: This is where Windsurf shines. I use SWE-1.6 as my primary coding companion for feature implementation. It understands our codebase context and writes production-ready code.
Real-world example: When I added OAuth authentication to our app, I used Cascade to implement it file-by-file. I started with the controller, then the service layer, then the repository, then tests. Windsurf maintained consistency across all files, following our existing patterns in the auth/ directory. What would have taken me 2 hours manually took 20 minutes with Windsurf.
My workflow: I give Windsurf specific, context-aware prompts like: "Implement the user registration flow following our existing patterns in auth/ directory. Start with the controller, then service layer, then repository. Use our existing User model and follow the pattern in auth/login.ts."
Model strategy: SWE-1.6 is the default for everything. It's free and achieves near-Claude 4.5 performance on coding benchmarks. Only escalate to Sonnet 4.6 or GPT-5.4 if SWE-1.6 struggles with the specific task.
Advanced technique: I combine Tab autocomplete with Cascade for maximum velocity. Tab handles the small inline edits while Cascade manages multi-file changes. For example, I implemented a new API endpoint in 15 minutes by having Windsurf generate the controller, tests, and documentation in parallel.
Best practice: Break large features into smaller, focused sessions. Long implementation sessions with paid models burn quota fast. Use SWE-1.6 for the bulk of the work.
🔄 Iterative Implementation Workflow
Me Windsurf (SWE-1.6) Codebase
│ │ │
│── "Implement OAuth" ────►│ │
│ following auth/ pattern │ │
│ │ │
│ │── Read auth/login.ts ───►│
│ │ (pattern matching) │
│ │◄── Pattern loaded ──────│
│ │ │
│ │── Generate controller ──►│
│ │ auth/oauth.ts │
│ │◄── File created ─────────│
│ │ │
│◄── "Controller done" ────│ │
│ │ │
│── "Now service layer" ──►│ │
│ │ │
│ │── Generate service ─────►│
│ │ auth/oauth.service.ts │
│ │◄── File created ─────────│
│ │ │
│◄── "Service done" ───────│ │
│ │ │
│── "Now repository" ─────►│ │
│ │ │
│ │── Generate repository ──►│
│ │ auth/oauth.repo.ts │
│ │◄── File created ─────────│
│ │ │
│◄── "All done, add tests"─│ │
│ │── Generate tests ───────►│
│ │ auth/oauth.test.ts │
│ │◄── Tests created ────────│
│ │ │
│◄── "OAuth implemented" ──│ │
📁 File Dependency: OAuth Implementation
auth/
├── login.ts (existing pattern)
│ └── exports: LoginController, LoginService, LoginRepository
│
├── oauth.ts (NEW - generated by Windsurf)
│ ├── OAuthController
│ │ ├── follows LoginController pattern
│ │ ├── uses OAuthService
│ │ └── exports: oauthRoutes
│ │
│ ├── oauth.service.ts (NEW)
│ │ ├── follows LoginService pattern
│ │ ├── uses OAuthRepository
│ │ └── handles: token exchange, user lookup
│ │
│ └── oauth.repo.ts (NEW)
│ ├── follows LoginRepository pattern
│ ├── uses existing User model
│ └── handles: OAuth tokens, user sessions
│
└── oauth.test.ts (NEW)
├── tests all three layers
├── follows existing test patterns
└── covers: success, failure, edge cases
Key: Windsurf maintains consistency across all files
by reading existing patterns and applying them uniformly.
What I do: I use Windsurf to generate unit tests, integration tests, and edge case coverage. It's particularly good at suggesting test scenarios I might miss.
Real-world example: For our payment processing logic, I asked Windsurf to generate comprehensive tests. It identified edge cases our team hadn't considered: timeout scenarios during payment processing, idempotency checks for duplicate payment attempts, and handling of partial refunds. Windsurf found 3 critical bugs in our discount calculation logic that manual testing missed — a race condition in the coupon application, a precision error in percentage calculations, and a missing validation for expired coupons.
My workflow: I use Windsurf for property-based testing and edge case discovery. My prompt: "Generate unit tests for the payment service covering success cases, failure cases, timeout scenarios, idempotency checks, and edge cases with invalid inputs. Use our existing test patterns in tests/payment/."
Model strategy: SWE-1.6 for standard test generation. For boilerplate test code or simple test cases, Claude Haiku 4.5 is the most cost-effective choice — excellent quality at ~$1.20/$6 per 1M tokens.
Advanced technique: I use Windsurf to analyze existing code and suggest missing test coverage. I feed it the function and ask: "What test cases am I missing for this function?" It often catches edge cases I overlooked. I also use it for test-driven development — I describe the behavior, have Windsurf generate failing tests, then implement the feature to make them pass.
Best practice: Never use Opus for test generation. The quality gain over Haiku or SWE-1.6 is negligible for most testing tasks, but the cost difference is massive.
📋 Test Coverage Matrix: Payment Processing
┌─────────────────────────────────────────────────────────────┐
│ TEST CATEGORIES │
├─────────────────────────────────────────────────────────────┤
│ │
│ SUCCESS CASES │
│ ├─ Valid payment with credit card │
│ ├─ Valid payment with PayPal │
│ ├─ Valid payment with crypto │
│ └─ Multi-item cart payment │
│ │
│ FAILURE CASES │
│ ├─ Insufficient funds │
│ ├─ Invalid card number │
│ ├─ Expired card │
│ ├─ Payment gateway timeout │
│ └─ Network failure │
│ │
│ EDGE CASES (Windsurf-discovered) │
│ ├─ Duplicate payment attempt (idempotency) ✓ │
│ ├─ Partial refund handling │
│ ├─ Coupon expiration validation ✓ │
│ ├─ Percentage precision error ✓ │
│ ├─ Race condition in coupon application ✓ │
│ └─ Zero-amount payment │
│ │
│ INTEGRATION TESTS │
│ ├─ Payment → Inventory update │
│ ├─ Payment → Order creation │
│ ├─ Payment → Email notification │
│ └─ Payment → Analytics tracking │
│ │
└─────────────────────────────────────────────────────────────┘
✓ = Bugs found by Windsurf that manual testing missed
🔄 TDD Workflow with Windsurf
┌─────────────┐
│ Feature │
│ Request │
└──────┬──────┘
│
▼
┌─────────────┐ SWE-1.6 (Free)
│ Describe │ ───────────────► Generate failing tests
│ Behavior │ based on spec
└──────┬──────┘
│
▼
┌─────────────┐
│ Run Tests │ ───────────────► All tests fail
└──────┬──────┘ (expected)
│
▼
┌─────────────┐ SWE-1.6 (Free)
│ Implement │ ───────────────► Write minimal code
│ Feature │ to pass tests
└──────┬──────┘
│
▼
┌─────────────┐
│ Run Tests │ ───────────────► All tests pass ✓
└──────┬──────┘
│
▼
┌─────────────┐ SWE-1.6 (Free)
│ Refactor │ ───────────────► Improve code quality
│ Code │ tests still pass
└─────────────┘
What I do: When bugs appear, I use Windsurf to trace through code, identify root causes, and generate fixes. The Cascade agent is particularly useful for complex debugging workflows.
Real-world example: When our production service started timing out under load, I fed Windsurf the stack traces and it identified an N+1 query problem in our ORM usage. It traced the issue through 5 microservices, showing how a single user request was triggering 47 database queries instead of 3. Windsurf generated a fix that reduced response time from 2.3 seconds to 180ms. Another time, Windsurf traced a memory leak across our microservices by analyzing the request flow and identifying a circular dependency in our caching layer that was causing objects to never be garbage collected.
My workflow: I provide Windsurf with error messages, stack traces, and relevant code snippets. My prompt: "Here's the error and stack trace. The service is timing out under load. Trace through the code to identify the root cause and suggest a fix. Consider the interaction between these files: [list files]."
Model strategy: Start with SWE-1.6 — it handles most bugs. For logic-heavy or hard-to-reproduce bugs, escalate to Claude Sonnet 4.6 Thinking. The thinking mode helps reason through complex logic step-by-step. Only use Opus 4.6 as a last resort.
Advanced technique: I use Windsurf's multi-file context to debug across services. I open all relevant files and ask Windsurf to trace the execution path. For distributed system issues, I use Sonnet 4.6 Thinking to reason through race conditions and timing issues. I also use Windsurf to generate reproduction steps and minimal test cases that isolate the bug.
Best practice: Provide clear reproduction steps and error messages. The better context you give, the faster and cheaper the fix will be.
🔍 Debugging Workflow
┌─────────────┐
│ Symptom: │
│ Bug/Error │
└──────┬──────┘
│
▼
┌─────────────┐ SWE-1.6 (Free)
│ Collect │ ───────────────► Gather: error messages,
│ Context │ stack traces, logs,
│ │ relevant code files
└──────┬──────┘
│
▼
┌─────────────┐ SWE-1.6 (Free)
│ Analyze │ ───────────────► Trace execution path,
│ Logs │ identify patterns
└──────┬──────┘
│
▼
┌─────────────┐
│ Formulate │
│ Hypothesis │
└──────┬──────┘
│
▼
┌─────────────┐ Sonnet 4.6 Thinking
│ Deep Dive │ ───────────────► Step-by-step reasoning
│ (if needed)│ for complex logic
└──────┬──────┘
│
▼
┌─────────────┐ SWE-1.6 (Free)
│ Generate │ ───────────────► Create fix, add tests
│ Fix │ to prevent regression
└──────┬──────┘
│
▼
┌─────────────┐
│ Verify & │
│ Deploy │
└─────────────┘
🌐 Distributed System Debug: N+1 Query Problem
Client Request
│
▼
┌─────────────┐
│ API Gateway │
└──────┬──────┘
│
├─────────────────────────────────────────┐
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ User Service│ │ Order Service│
│ (1 query) │ │ (1 query) │
└──────┬──────┘ └──────┬──────┘
│ │
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Order Repo │ │ Product SVC │
│ (N queries)│ ◄───────────────────────│ (N queries)│
│ N+1 BUG! │ For each order item │ N+1 BUG! │
└─────────────┘ └─────────────┘
│ │
└────────────────────────────────────────┘
│
▼
┌─────────────┐
│ Database │
│ (47 total) │
└─────────────┘
Windsurf identified:
• Order service fetches orders (1 query)
• For each order, fetches items (N queries) ← N+1
• For each item, fetches product details (N queries) ← N+1
• Total: 1 + N + N = 47 queries for 23 orders
Fix: Use eager loading with JOIN
Result: 47 queries → 3 queries (2.3s → 180ms)
What I do: I use Windsurf to write deployment scripts, configure CI/CD pipelines, and troubleshoot production issues. It's great for generating Docker configs, Kubernetes manifests, and infrastructure-as-code.
Real-world example: I had Windsurf generate our complete GitHub Actions workflow with build, test, security scan, and deploy stages. It also created Docker multi-stage builds for our services, Kubernetes manifests with proper resource limits, and Helm charts for deployment. Windsurf helped us design a blue-green deployment strategy that reduced our deployment downtime from 30 minutes to 2 minutes. It also generated monitoring dashboards and alerting rules for Prometheus and Grafana.
My workflow: I give Windsurf our infrastructure requirements and ask: "Generate a complete CI/CD pipeline using GitHub Actions with stages for build, test, security scan, and deploy to Kubernetes. Include Docker multi-stage builds and Helm charts. Follow our existing patterns in .github/workflows/."
Model strategy: SWE-1.6 for most deployment tasks. For reading large config files or analyzing complex infrastructure, Gemini 3.1 Pro offers the best value with strong long-context capability at ~$2.40/$14.40 per 1M tokens.
Advanced technique: I use Windsurf for disaster recovery planning and documentation. I ask it to generate rollback procedures, runbooks for common incidents, and infrastructure diagrams. I also use it to generate monitoring dashboards and alerting rules based on our application metrics. Windsurf is excellent at generating Terraform or CloudFormation templates from infrastructure descriptions.
Best practice: Keep deployment sessions focused on specific tasks. Don't use expensive models for routine config file edits.
🚀 CI/CD Pipeline with Windsurf Integration
┌─────────────┐
│ Push to │
│ GitHub │
└──────┬──────┘
│
▼
┌─────────────┐ SWE-1.6 (Free)
│ Build │ ───────────────► Generate Dockerfile
│ Stage │ multi-stage build
└──────┬──────┘
│
▼
┌─────────────┐ SWE-1.6 (Free)
│ Test │ ───────────────► Run unit & integration
│ Stage │ tests
└──────┬──────┘
│
▼
┌─────────────┐ Haiku 4.5 (Low cost)
│ Security │ ───────────────► Run security scans
│ Scan │ (SAST, dependency check)
└──────┬──────┘
│
▼
┌─────────────┐ SWE-1.6 (Free)
│ Deploy │ ───────────────► Deploy to staging
│ Staging │ using Helm
└──────┬──────┘
│
▼
┌─────────────┐
│ E2E Tests │
└──────┬──────┘
│
▼
┌─────────────┐ SWE-1.6 (Free)
│ Deploy │ ───────────────► Blue-green deploy
│ Production │ to production
└──────┬──────┘
│
▼
┌─────────────┐
│ Monitor │
│ & Alert │
└─────────────┘
🔄 Deployment Strategy Comparison
ROLLING DEPLOYMENT (Old approach)
────────────────────────────────
Version 1: ████████████████████ 100%
Version 2: ░░░░░░░░░░░░░░░░░░░ 0%
Step 1: V1: ███████████████░░░ 90%
V2: ░░░░░░░░░░░░██░░░ 10%
Step 2: V1: █████████░░░░░░░░░ 70%
V2: ░░░░░░░░░░░██░░░░░ 30%
Step 3: V1: █████░░░░░░░░░░░░░ 50%
V2: ░░░░░░░░░░██░░░░░░░ 50%
... gradual shift ...
Result: 30 min downtime, risk of partial failures
───────────────────────────────────────────────
BLUE-GREEN DEPLOYMENT (Windsurf-designed)
────────────────────────────────────────
Version 1 (Blue): ████████████████████ 100% (Live)
Version 2 (Green): ░░░░░░░░░░░░░░░░░░░ 0% (Idle)
Step 1: Deploy V2 to Green
V1 (Blue): ████████████████████ 100% (Live)
V2 (Green): ████████████████████ 100% (Ready)
Step 2: Run smoke tests on Green
V2 (Green): ✓ All tests pass
Step 3: Switch traffic to Green
V1 (Blue): ░░░░░░░░░░░░░░░░░░░ 0% (Idle)
V2 (Green): ████████████████████ 100% (Live)
Step 4: Keep Blue as rollback option
Result: 2 min downtime, instant rollback available
───────────────────────────────────────────────
CANARY DEPLOYMENT (Windsurf alternative)
────────────────────────────────────────
Version 1: ████████████████████ 100%
Version 2: ░░░░░░░░░░░░░░░░░░░ 0%
Step 1: V2: ░░░░░░░░░░░░░░░░░░░ 5% (canary)
Step 2: Monitor metrics ✓
Step 3: V2: ░░░░░░░░░░░░░░░░░░░ 25%
Step 4: Monitor metrics ✓
Step 5: V2: ████████████████████ 100%
Result: Gradual rollout, catch issues early
How the top 1% AI users leverage Windsurf
What top users do differently: The top 1% of AI-assisted developers don't just ask Windsurf to "write code" — they use it as a thought partner for architecture, a reviewer for code quality, and a teacher for new technologies. They've developed specific patterns that multiply Windsurf's effectiveness.
Pattern 1: Code review at scale: Instead of reviewing every line manually, I use Windsurf to do first-pass reviews. I ask: "Review this PR for bugs, security issues, and consistency with our codebase patterns." Windsurf catches 80% of issues before I even look at it. This lets me focus on the 20% that actually needs human judgment.
Pattern 2: Complex refactoring with the agent system: When refactoring across multiple files, I use Cascade's agent capabilities. I give it a high-level goal: "Refactor the authentication system to use a strategy pattern for different OAuth providers." Cascade autonomously navigates the codebase, makes changes across 15+ files, and ensures consistency. What would take me a day takes Cascade 30 minutes.
Pattern 3: Documentation as a first-class citizen: I use Windsurf to generate and maintain documentation alongside code. Every time I implement a feature, I ask Windsurf to generate API docs, update the README, and create inline comments. This keeps documentation in sync with code automatically.
Pattern 4: Maintaining context across long sessions: Top users know how to structure long sessions. I start with a clear context-setting message: "We're working on the payment system refactoring. Here's the current state: [summary]. Here are the files involved: [list]. Here's our goal: [goal]." This keeps Windsurf aligned throughout multi-hour sessions.
Pattern 5: Combining multiple models effectively: I don't just use one model. I start with SWE-1.6 for the bulk of work. When I hit a blocker, I escalate to Sonnet 4.6 for deeper reasoning. For infrastructure tasks, I use Gemini 3.1 Pro for its long-context capabilities. Each model has strengths — top users play to them.
Real productivity gains: The developers I've mentored who adopt these patterns see 3-5x productivity improvements. One senior engineer reduced her feature implementation time from 2 days to 4 hours by using Windsurf for architecture, implementation, testing, and documentation in an integrated workflow.
📅 Daily Development Cycle: Top 1% User
09:00 AM ──► Morning Standup
│
▼
09:15 AM ──► Review PRs with Windsurf (SWE-1.6)
• First-pass automated review
• Focus on 20% needing human judgment
│
▼
10:00 AM ──► Feature Implementation (SWE-1.6 + Cascade)
• Architecture discussion
• File-by-file implementation
• Tab autocomplete for inline edits
│
▼
12:00 PM ──► Lunch
│
▼
01:00 PM ──► Testing & Debugging (SWE-1.6 → Sonnet if needed)
• Generate tests (SWE-1.6)
• Debug issues (escalate to Sonnet Thinking)
│
▼
03:00 PM ──► Code Review (Windsurf-assisted)
• Self-review with Windsurf
• Generate documentation
│
▼
04:00 PM ──► Infrastructure/Deployment (SWE-1.6)
• Update CI/CD configs
• Deploy to staging
│
▼
05:00 PM ──► Learning & Research (Haiku/Sonnet)
• Explore new libraries
• Research best practices
│
▼
06:00 PM ──► End of Day
• Windsurf handled 80% of routine tasks
• Focus time on high-value work
📊 Productivity Comparison: Manual vs Windsurf-Assisted
Feature Implementation
4h
Why Windsurf is worth it
💡 The Windsurf advantage
✓
SWE-1.6 is completely free — purpose-built for coding, near-frontier performance, zero quota cost. This alone makes it worth it.
✓
Unified interface across providers — Claude, GPT, Gemini, xAI, DeepSeek, and more in one place. No context switching.
✓
Cascade agent system — optimized for coding workflows with multi-tool coordination. Better than raw API calls.
✓
Quota-based predictable pricing — daily and weekly budgets. No surprise bills. Run out? Just wait for reset.
✓
IDE-native integration — works directly in your code editor. Context-aware, file-aware, repo-aware.
✓
Model selection guidance — this guide itself shows how to pick the right model for every task. Optimized for cost-efficiency.
Competitor comparison
| Tool |
Pricing |
Limitations |
Windsurf advantage |
| GitHub Copilot |
$10/mo individual
$19/user/mo business |
Single model (GPT-based), no model selection, limited context window, no quota control |
Free SWE models, multiple providers, better cost control, IDE-native context |
| Cursor |
$20/mo Pro
$40/mo Business |
Higher cost, less flexible model selection, limited provider options |
Lower cost, more model variety, quota system with predictable spending |
| Claude.ai Direct |
$20/mo Pro
API usage-based |
No IDE integration, separate from coding workflow, context switching overhead |
IDE-native, multiple providers in one interface, coding-optimized workflow |
| ChatGPT Plus |
$20/mo |
General-purpose, not coding-optimized, no IDE integration, no codebase context |
Purpose-built coding models, integrated workflow, repo-aware context |
| Windsurf |
Quota-based
SWE-1.6: Free |
None significant — this is the advantage |
Free frontier coding models, unified multi-provider interface, predictable costs |
Here's the math from my team's actual usage: With SWE-1.6 being completely free and handling 80-90% of coding tasks, our actual paid model usage is minimal. In Q1 2026, our team of 5 developers used an average of $12/month per developer in paid quota — that's $144/year per developer. Compare that to GitHub Copilot at $228/year per developer regardless of usage.
Specific time savings: What took 4 hours manually now takes 30 minutes with Windsurf — that's 8x productivity improvement. For our OAuth implementation, manual work would have taken 2 hours; with Windsurf it took 20 minutes. For the N+1 query debug, manual investigation would have taken 4 hours; with Windsurf it took 30 minutes.
Real ROI calculation: Our team saves approximately 20 hours per week per developer using Windsurf. At $100/hour, that's $2,000/week in savings. Subtract the $12/month per developer cost, and the net savings is $7,988 per developer per year. That's a 66:1 return on investment.
The ROI: Better models, more choices, coding-optimized experience, and often lower total cost. That's why I standardized our team on Windsurf.
💰 Annual Cost Comparison Per Developer
Windsurf (usage-based, 80% free)
📈 ROI Over Time: Windsurf Investment
Monthly Breakdown (Per Developer)
────────────────────────────────
Time Savings Value: 20 hrs/week × $100/hr = $2,000/week
= $8,000/month
Windsurf Cost: $12/month (paid quota)
+ $0/month (SWE-1.6 is free)
= $12/month
Net Monthly Savings: $8,000 - $12 = $7,988/month
Net Annual Savings: $7,988 × 12 = $95,856/year
ROI Calculation:
────────────────────────────────
Investment: $144/year
Return: $95,856/year (time savings value)
ROI: 66,533% (66,533% return on investment)
Payback Period: 0.18 days (less than 5 hours)
Note: This calculation assumes:
• Developer time valued at $100/hour
• 20 hours/week saved using Windsurf
• $12/month average paid quota usage
• SWE-1.6 handles 80% of tasks (free)
Your actual ROI may vary based on:
• Developer hourly rate
• Usage patterns
• Quota plan tier
• Team size