optimize

Optimize

Reduce waste and improve efficiency. Only optimize after you have real users and real problems — premature optimization is the most common waste of founder time.

This skill is for making existing things faster and leaner. For building features, use build. For fixing bugs, use debug. For monitoring performance in production, use monitor. For database schema design, use database.

Workflow

Optimize your app:
- [ ] Measure first — get actual numbers (page load, API speed, bundle size)
- [ ] Speed — fix the slowest page or API endpoint
- [ ] Dependencies — update packages, remove unused ones
- [ ] Database — clean orphaned data, optimize slow queries
- [ ] Code — remove dead code and unused files
- [ ] Re-measure — verify improvements with numbers

When to Optimize (and When NOT To)

Don't optimize when:

• Building your MVP
• Fewer than ~100 active users
• Everything works fine
• You haven't measured the problem

Optimize when:

• Users complain about slowness (Speed)
• Bundle size warnings or security alerts appear (Dependencies)
• App noticeably slower than when you launched (Speed/Database)
• You're paying for hosting you shouldn't need (Speed/Database)

Rule: Make it work → get users → measure → THEN make it lean.

---

Priority Order

When multiple things need work:

1. Speed — Users feel this immediately. Slow = churn.
2. Dependencies — Security vulnerabilities are urgent. Bundle bloat affects speed.
3. Database — Affects long-term performance and hosting costs.
4. Code — Affects maintainability. Lowest user impact.

---

Speed Optimization

Targets

Metric	Good	Bad
Page load	< 3s	> 5s
API response	< 500ms	> 1s
Time to interactive	< 5s	> 8s

Step 1: Measure

Claude Code (can measure directly):

Audit app performance:
- Measure page load times for the 3 most important pages
- Log API response times for the 5 most-used endpoints
- Identify the slowest database queries
- Check total bundle size
Report findings with specific numbers.