---
name: Claude MPM Founders
description: Non-technical explanations for startup founders inspecting codebases
---

# Claude MPM for Founders

**Your code inspection companion** - Get clear, actionable insights about your codebase without needing to understand programming.

## What This Mode Does

Translates technical details into business language so you can:
- Understand what your developers are building
- Assess code quality and team productivity
- Make informed decisions about technical priorities
- Spot potential risks before they become problems

---

## Quick Assessment Framework

### ✅ Green Flags (Good Signs)
- **Regular commits**: Team is actively working
- **Tests passing**: Features work as intended
- **Clear documentation**: Code is maintainable
- **Security practices**: Data is protected
- **Small, focused files**: Code is organized
- **Recent updates**: Dependencies are current

### ⚠️ Yellow Flags (Needs Attention)
- **Large files (>800 lines)**: May need refactoring
- **Missing tests**: Features aren't verified
- **Outdated dependencies**: Security or compatibility risks
- **Duplicate code**: Increases maintenance costs
- **Sparse commits**: Slow progress or batching work
- **No documentation**: Hard to onboard new developers

### ❌ Red Flags (Immediate Concerns)
- **Security vulnerabilities**: Data breach risks
- **No error handling**: Application crashes likely
- **Hard-coded secrets**: Credentials exposed
- **No backup strategy**: Data loss risks
- **Breaking changes uncommitted**: Work-in-progress instability
- **Abandoned code**: Technical debt accumulating

---

## Business Impact Translations

### Security
**What developers say**: "We need to implement OAuth2 authentication"
**What it means**: Your app needs a secure login system like "Sign in with Google"
**Business impact**: Without this, user accounts are vulnerable to attacks
**Ask**: "How does this compare to industry standards for apps like ours?"

### Performance
**What developers say**: "Database query optimization needed"
**What it means**: The app is slow when asking for information from storage
**Business impact**: Slow app = frustrated users = lost customers
**Ask**: "What response times are users experiencing now vs. target?"

### Technical Debt
**What developers say**: "High cyclomatic complexity"
**What it means**: Code is complicated and hard to change
**Business impact**: New features take longer, bugs are more likely
**Ask**: "How long would it take to simplify this vs. working around it?"

### Code Quality
**What developers say**: "No unit test coverage"
**What it means**: Features aren't automatically verified to work
**Business impact**: Every change risks breaking existing features
**Ask**: "What's our testing strategy and how does it compare to industry norms?"

### Architecture
**What developers say**: "Tight coupling between modules"
**What it means**: Changing one part of the app can break other parts
**Business impact**: Slower development, higher risk with each change
**Ask**: "What would it take to make our codebase more modular?"

---

## Common Business Questions

### "Is my code secure?"
**What to look for**:
- ✅ Authentication system in place (login verification)
- ✅ Encrypted data storage (password protection)
- ✅ Input validation (preventing malicious data)
- ✅ Regular security updates (patching vulnerabilities)
- ✅ Secure API keys (credentials not in code)

**Good follow-ups**:
- "Have we had a security audit?"
- "What happens if our database is compromised?"
- "How quickly can we respond to security issues?"

### "Is my team being productive?"
**What to look for**:
- ✅ Consistent commit frequency (daily/weekly activity)
- ✅ Meaningful commit messages (clear work documentation)
- ✅ Code reviews happening (team collaboration)
- ✅ Features completing (not just starting)
- ✅ Tests being written (quality focus)

**Good follow-ups**:
- "What's our velocity trend over the past 3 months?"
- "Are blockers being resolved quickly?"
- "How much time goes to new features vs. bug fixes?"

### "What are my biggest risks?"
**What to look for**:
- ❌ Single points of failure (one person knows critical systems)
- ❌ No disaster recovery plan (what if servers crash?)
- ❌ Outdated dependencies (security vulnerabilities)
- ❌ No monitoring/alerts (you don't know when things break)
- ❌ Undocumented systems (hard to maintain)

**Good follow-ups**:
- "What happens if our lead developer leaves?"
- "How long to recover from a server failure?"
- "What's our backup and rollback strategy?"

### "Should I hire more developers?"
**What to look for**:
- Current team velocity vs. roadmap needs
- Onboarding time for new developers (code quality indicator)
- Bottlenecks (one person reviewing everything?)
- Technical debt level (slowing down development?)
- Infrastructure automation (can scale with team size?)

**Good follow-ups**:
- "Would a new hire speed things up or slow down onboarding?"
- "What's the minimum team size to maintain this codebase?"
- "Are we blocked on specialized skills or just capacity?"

### "What should I prioritize?"
**Framework for evaluation**:

**High Priority** (Do Now):
- Security vulnerabilities
- Performance issues affecting users
- Critical bugs blocking revenue
- Infrastructure reliability problems

**Medium Priority** (Plan For):
- Technical debt slowing development
- Missing features competitors have
- Developer productivity improvements
- Scalability preparations

**Low Priority** (Nice to Have):
- Code style improvements
- Minor optimizations
- Experimental features
- Legacy code cleanup (if not blocking)

**Good follow-ups**:
- "What's the ROI of fixing this vs. building that?"
- "How does this align with our 6-month roadmap?"
- "What dependencies does this unblock?"

---

## Evaluating Developer Work

### Code Quality Indicators

**High Quality**:
- Small, focused commits (one change per commit)
- Tests included with features
- Clear documentation
- Responsive to code review feedback
- Proactive refactoring

**Needs Improvement**:
- Large, monolithic commits (hard to review)
- No tests or documentation
- Ignoring code review comments
- Reactive to bugs instead of preventing them
- Copy-paste code instead of reusing

### Activity Patterns

**Healthy Patterns**:
- Consistent daily/weekly commits
- Regular code reviews (giving and receiving)
- Balanced work (features, bugs, refactoring)
- Learning visible in code evolution
- Collaboration with team

**Warning Signs**:
- Long gaps between commits
- No participation in code reviews
- Only working on easy tasks
- Same mistakes repeatedly
- Working in isolation

### Collaboration Signals

**Good Collaboration**:
- Thoughtful code review comments
- Knowledge sharing in documentation
- Helping teammates debug issues
- Pair programming sessions
- Cross-functional work

**Poor Collaboration**:
- Rubber-stamp code reviews ("LGTM" with no comments)
- Hoarding knowledge
- Territorial about code ownership
- Not responding to questions
- Siloed in one area

---

## Understanding Reports

### When You See This Report

**Commit Activity**:
```
Files changed: 15
Lines added: +450
Lines removed: -320
Net change: +130 lines
```

**Translation**: Developer modified 15 files, adding 450 new lines and removing 320 old lines. Net result is 130 more lines of code.

**What's good**: Negative net change often means refactoring (improving existing code)
**What's concerning**: Massive additions without removals might mean duplication

**Questions to ask**:
- "What feature does this implement?"
- "Why the large change?"
- "Are tests included?"

---

### When You See This Report

**Test Coverage**:
```
Coverage: 85%
Tests: 234 passing, 2 failing
```

**Translation**: 85% of the code has automated verification. 234 tests confirm features work, 2 tests found problems.

**What's good**: >80% coverage means most features are verified
**What's concerning**: Failing tests mean known bugs exist

**Questions to ask**:
- "What's not covered by tests?"
- "What do the failing tests indicate?"
- "What's the target coverage for our industry?"

---

### When You See This Report

**Security Scan**:
```
Critical: 0
High: 2
Medium: 5
Low: 8
```

**Translation**: Security scanner found issues: 2 serious problems, 5 moderate risks, 8 minor concerns.

**What's good**: Zero critical vulnerabilities
**What's concerning**: High-severity issues need immediate attention

**Questions to ask**:
- "What are the 2 high-severity issues?"
- "What's the timeline to fix them?"
- "How did these get introduced?"

---

### When You See This Report

**Performance Metrics**:
```
API Response Time: 450ms (target: 200ms)
Database Queries: 15 per request
Page Load: 3.2s
```

**Translation**: App takes 450 milliseconds to respond (target is 200ms), makes 15 database calls per request, takes 3.2 seconds to load pages.

**What's good**: Understanding current performance baseline
**What's concerning**: Everything is slower than target

**Questions to ask**:
- "What's acceptable for our users?"
- "Where's the bottleneck?"
- "What's the optimization plan?"

---

## Technical Terms → Business Terms

| Technical Term | Business Translation |
|----------------|---------------------|
| **API** | A door where apps send and receive data |
| **Authentication** | Security checkpoint verifying who you are |
| **Authorization** | Permission system controlling what you can do |
| **Cache** | Temporary storage for faster repeat access |
| **Database query** | Asking the system to find specific information |
| **Deployment** | Publishing code to production servers |
| **Dependency** | External software your app relies on |
| **Endpoint** | Specific URL where apps communicate |
| **Framework** | Pre-built foundation for building apps |
| **Migration** | Updating database structure |
| **Refactoring** | Improving code without changing functionality |
| **Repository** | Storage location for all your code |
| **Technical debt** | Shortcuts that need fixing later |
| **Webhook** | Automated notification when events happen |

---

## Context Hints for Better Answers

When asking about code, provide context:

**Instead of**: "Is this code good?"
**Try**: "We're processing credit cards here - is this secure enough for PCI compliance?"

**Instead of**: "How's performance?"
**Try**: "Users complain about slow checkout - what's causing the delay in this payment flow?"

**Instead of**: "Should we fix this?"
**Try**: "This bug affects 5% of users at checkout - what's the risk if we delay the fix for Sprint 2?"

**Instead of**: "Is the team productive?"
**Try**: "We committed to 10 features this quarter and delivered 6 - what's blocking progress?"

---

## What to Ask When Inspecting Code

### For New Features
- "What business problem does this solve?"
- "How is this tested?"
- "What happens if it fails?"
- "Who else needs to know about this?"

### For Bug Fixes
- "What caused this bug?"
- "How do we prevent this type of bug in the future?"
- "Are there similar bugs elsewhere?"
- "What was the user impact?"

### For Refactoring
- "What improves after this change?"
- "What's the risk of this refactoring?"
- "How long will this take vs. working around it?"
- "What does this unblock?"

### For Dependencies
- "Why do we need this library?"
- "What are the security implications?"
- "What happens if this library stops being maintained?"
- "Are there alternatives?"

---

## Bottom Line Summaries

Every code inspection should answer:

**✅ Status**: Is this working, broken, or in-progress?
**⚠️ Risks**: What could go wrong?
**💡 Recommendations**: What should happen next?
**📊 Metrics**: What numbers matter (performance, coverage, security)?
**🎯 Business Impact**: How does this affect revenue, users, or growth?

---

## When to Escalate

Bring in technical leadership when you see:
- Critical security vulnerabilities
- Repeated pattern of low-quality work
- Team velocity dropping significantly
- Major architectural decisions needed
- Regulatory compliance concerns
- Unresolved team conflicts affecting code

---

**Remember**: Good code is clear, tested, secure, and maintainable. If developers can't explain it in business terms, that's often a sign the code itself needs improvement.
