Converting proven PI (Profitability Index) strategy into a high-performing Cursor rule that 100x's code-generated value

profit-mindset.mdc

---
description: Core Philosophy is Maximum Value per Development Dollar
globs:
    - "**/*.md"
alwaysApply: true
---
# Profitability Index-Focused Cursor Rules

## Core Philosophy: Maximum Value per Development Dollar

Apply Profitability Index (PI) thinking to all code decisions. Every line of code should generate more value than it costs to write, maintain, and operate.

## 1. Value-Oriented Development

### Calculate Development ROI
- **Before coding**: Estimate time investment vs. expected benefit
- **Favor high PI features**: Prioritize functionality that delivers maximum value per development hour
- **Consider maintenance costs**: Factor in long-term support and updates as part of initial investment

### Code Investment Decisions
```python
# HIGH PI: Simple, reusable utility
def format_currency(amount):
    return f"${amount:,.2f}"

# LOW PI: Over-engineered solution for simple problem  
class CurrencyFormatterFactory:
    def create_formatter(self, locale, precision, symbol):
        # 50 lines of unnecessary complexity
```

## 2. Present Value of Code

### Time Value Principle
- **Immediate value delivery**: Write code that provides benefits now, not just future promises
- **Incremental improvements**: Small, frequent enhancements over large, delayed features
- **Depreciation awareness**: Consider how quickly code becomes obsolete

### Future Cash Flow Estimation
- Estimate how long code will remain useful
- Factor in maintenance burden over time
- Prioritize evergreen solutions over trend-chasing implementations

## 3. Comparative Project Analysis

### Multi-Option Evaluation
When choosing between implementations:
```python
# Option A: PI = 2.1 (High value, moderate effort)
# Simple REST API with basic validation

# Option B: PI = 1.2 (Lower efficiency despite more features)  
# Complex GraphQL with extensive caching but high maintenance

# Option C: PI = 0.8 (Unprofitable - avoid)
# Over-architected microservices for simple CRUD
```

### Resource Allocation
- **Limited bandwidth**: Focus on highest PI tasks first
- **Team capacity**: Consider developer skill levels in PI calculations
- **Technical debt**: Factor cleanup costs into investment analysis

## 4. Code Quality Standards

### High PI Code Characteristics
- **Readable**: Low cognitive load = faster debugging/maintenance
- **Reusable**: Higher value extraction per investment
- **Testable**: Reduces future defect costs
- **Performant**: Delivers user value efficiently

### Code Review Checklist
- [ ] Does this solve a real problem worth the implementation cost?
- [ ] Is this the simplest solution that works?
- [ ] Will this code pay dividends over time?
- [ ] Are we solving the right problem at the right scale?

## 5. Architecture Decisions

### Profitability-Driven Design
```python
# HIGH PI: Start simple, scale when needed
class UserService:
    def __init__(self):
        self.users = []  # In-memory for MVP
        
    def add_user(self, user):
        self.users.append(user)
        return user

# MEDIUM PI: Database when complexity justifies investment
class UserService:
    def __init__(self, db_connection):
        self.db = db_connection
        
# LOW PI: Premature optimization
class UserService:
    def __init__(self, cache, db, message_queue, search_index):
        # Complexity without proven need
```

### Technology Selection
- **Proven over bleeding-edge**: Established tools have better PI
- **Learning curve consideration**: Factor team expertise into investment cost
- **Ecosystem maturity**: Libraries with good support have higher PI

## 6. Feature Development

### PI-Based Feature Prioritization
1. **Calculate expected value**: User impact × usage frequency × business value
2. **Estimate true cost**: Development + testing + maintenance + opportunity cost
3. **Compare alternatives**: Always consider 2-3 implementation approaches
4. **Validate assumptions**: Quick prototypes before full investment

### Minimum Viable Implementation
```python
# HIGH PI: Core functionality first
def process_payment(amount, card_token):
    """Process payment - core business value"""
    return stripe.charge(amount, card_token)

# Add later only if PI justifies:
# - Multiple payment providers
# - Advanced fraud detection  
# - Detailed analytics
# - Currency conversion
```

## 7. Performance as Profitability

### User Experience ROI
- **Fast load times**: Direct correlation to user satisfaction and conversion
- **Responsive UI**: Small investment, high user value
- **Error handling**: Prevents user frustration, maintains trust

### Resource Efficiency
```python
# HIGH PI: Efficient database queries
users = User.objects.select_related('profile').filter(active=True)

# LOW PI: N+1 queries that scale poorly
users = User.objects.filter(active=True)
for user in users:
    print(user.profile.name)  # Separate query each iteration
```

## 8. Technical Debt Management

### Debt as Negative PI
- **Interest accumulation**: Technical debt compounds over time
- **Repayment strategy**: Regular refactoring prevents debt crisis
- **Investment decisions**: Sometimes taking on small debt enables higher PI features

### Refactoring ROI
```python
# Before refactoring: Calculate PI
# Time to refactor: 4 hours
# Time saved per future modification: 30 minutes  
# Expected modifications per month: 3
# Break-even: 4 hours ÷ 0.5 hours = 8 months
# If feature lifetime > 8 months, refactoring has positive PI
```

## 9. Testing Investment

### Test PI Calculation
- **Unit tests**: High PI for complex business logic
- **Integration tests**: High PI for critical user paths
- **E2E tests**: Medium PI for happy paths, lower for edge cases
- **Manual testing**: Lowest PI - automate when possible

### Strategic Testing
```python
# HIGH PI: Test business-critical calculations  
def test_price_calculation():
    assert calculate_price(base=100, tax=0.1) == 110

# MEDIUM PI: Test error handling
def test_invalid_input():
    with pytest.raises(ValueError):
        calculate_price(base=-100, tax=0.1)

# LOW PI: Testing framework internals
def test_mock_was_called():
    # Usually not worth the maintenance burden
```

## 10. Documentation Strategy

### Documentation PI
- **README**: Extremely high PI - saves onboarding time
- **API docs**: High PI for public interfaces
- **Code comments**: Medium PI for complex logic only
- **Extensive design docs**: Lower PI unless team is large

### Effective Documentation
```python
def calculate_profitability_index(present_value: float, initial_investment: float) -> float:
    """
    Calculate Profitability Index for investment decisions.
    
    PI > 1.0 indicates profitable investment
    PI < 1.0 indicates unprofitable investment
    PI = 1.0 indicates break-even
    
    Args:
        present_value: Sum of discounted future cash flows
        initial_investment: Upfront cost of investment
        
    Returns:
        Profitability index ratio
        
    Raises:
        ValueError: If initial_investment is <= 0
    """
    if initial_investment <= 0:
        raise ValueError("Initial investment must be positive")
    
    return present_value / initial_investment
```

## 11. Measurement and Iteration

### Track Code PI Metrics
- **Development velocity**: Features delivered per sprint
- **Bug rates**: Quality per development hour
- **User satisfaction**: Value delivered per feature
- **Performance metrics**: User experience per optimization effort

### Continuous Improvement
- Regular PI assessment of completed projects
- Learn from high and low PI decisions
- Adjust estimation accuracy over time
- Share PI insights with team

## 12. Anti-Patterns to Avoid

### Low PI Code Smells
- **Gold-plating**: Adding features "just in case"
- **Premature optimization**: Complex solutions for simple problems
- **Technology tourism**: Using new tech without business justification
- **Over-engineering**: Building for imaginary future requirements
- **Analysis paralysis**: Perfect planning that delays valuable delivery

### PI Red Flags
```python
# RED FLAG: Complex inheritance for simple variation
class BaseUserProcessor:
    def process(self):
        raise NotImplementedError

class AdminUserProcessor(BaseUserProcessor):
    def process(self):
        return "admin processing"

# BETTER: Simple function with parameter
def process_user(user_type):
    if user_type == "admin":
        return "admin processing"
    return "regular processing"
```

## Summary

Every development decision should maximize the Profitability Index: delivering maximum value per development investment. Start simple, measure actual value delivery, and only add complexity when the PI calculation clearly justifies it. Remember: the best code is often the code you don't have to write.

**Golden Rule**: If you can't articulate why a piece of code will generate more value than it costs to build and maintain, reconsider whether it should be built at all.