Menu
Estimate development cost of a codebase based on lines of code and complexity
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | cost-estimate |
| description | Estimate development cost of a codebase based on lines of code and complexity |
| credit | https://x.com/toddsaunders/status/2029301170670309740/ |
You are a senior software engineering consultant tasked with estimating the development cost of the current codebase.
Read the entire codebase to understand:
Use the Glob and Read tools to systematically review:
Based on industry standards for a senior full-stack developer (5+ years experience):
Hourly Productivity Estimates:
Additional Time Factors:
Calculate total hours considering:
Use WebSearch to find current 2025 hourly rates for:
Search queries to use:
Real companies don't have developers coding 40 hours/week. Account for typical organizational overhead to convert raw development hours into realistic calendar time.
Weekly Time Allocation for Typical Company:
| Activity | Hours/Week | Notes |
|---|---|---|
| Pure coding time | 20-25 hrs | Actual focused development |
| Daily standups | 1.25 hrs | 15 min × 5 days |
| Weekly team sync | 1-2 hrs | All-hands, team meetings |
| 1:1s with manager | 0.5-1 hr | Weekly or biweekly |
| Sprint planning/retro | 1-2 hrs | Per week average |
| Code reviews (giving) | 2-3 hrs | Reviewing teammates' work |
| Slack/email/async | 3-5 hrs | Communication overhead |
| Context switching | 2-4 hrs | Interruptions, task switching |
| Ad-hoc meetings | 1-2 hrs | Unplanned discussions |
| Admin/HR/tooling | 1-2 hrs | Timesheets, tools, access requests |
Coding Efficiency Factor:
Calendar Weeks Calculation:
Calendar Weeks = Raw Dev Hours ÷ (40 × Efficiency Factor)
Example: 3,288 raw dev hours at 50% efficiency = 3,288 ÷ 20 = 164.4 weeks (~3.2 years)
Engineering doesn't ship products alone. Calculate the fully-loaded team cost including all supporting roles.
Supporting Role Ratios (expressed as ratio to engineering hours):
| Role | Ratio to Eng Hours | Typical Rate | Notes |
|---|---|---|---|
| Product Management | 0.25-0.40× | $125-200/hr | PRDs, roadmap, stakeholder mgmt |
| UX/UI Design | 0.20-0.35× | $100-175/hr | Wireframes, mockups, design systems |
| Engineering Management | 0.12-0.20× | $150-225/hr | 1:1s, hiring, performance, strategy |
| QA/Testing | 0.15-0.25× | $75-125/hr | Test plans, manual testing, automation |
| Project/Program Management | 0.08-0.15× | $100-150/hr | Schedules, dependencies, status |
| Technical Writing | 0.05-0.10× | $75-125/hr | User docs, API docs, internal docs |
| DevOps/Platform | 0.10-0.20× | $125-200/hr | CI/CD, infra, deployments |
Team Composition by Company Stage:
| Stage | PM | Design | EM | QA | PgM | Docs | DevOps |
|---|---|---|---|---|---|---|---|
| Solo/Founder | 0% | 0% | 0% | 0% | 0% | 0% | 0% |
| Lean Startup | 15% | 15% | 5% | 5% | 0% | 0% | 5% |
| Growth Company | 30% | 25% | 15% | 20% | 10% | 5% | 15% |
| Enterprise | 40% | 35% | 20% | 25% | 15% | 10% | 20% |
Full Team Multiplier:
Calculation:
Full Team Cost = Engineering Cost × Team Multiplier
Example: $500K engineering cost at Growth Company = $500K × 2.2 = $1.1M total team cost
Provide a comprehensive estimate in this format:
Analysis Date: [Current Date] Codebase Version: [From CLAUDE.md phase status]
Total Lines of Code: [number]
Complexity Factors:
Base Development Hours: [number] hours
Overhead Multipliers:
Total Estimated Hours: [number] hours
| Company Type | Efficiency | Coding Hrs/Week | Calendar Weeks | Calendar Time |
|---|---|---|---|---|
| Solo/Startup (lean) | 65% | 26 hrs | [X] weeks | ~[X] months |
| Growth Company | 55% | 22 hrs | [X] weeks | ~[X] years |
| Enterprise | 45% | 18 hrs | [X] weeks | ~[X] years |
| Large Bureaucracy | 35% | 14 hrs | [X] weeks | ~[X] years |
Overhead Assumptions:
Senior Full-Stack Developer Rates (2025):
Recommended Rate for This Project: $[X]/hour
Rationale: This project requires specialized macOS development skills (CoreMediaIO, Metal, system extensions) which command premium rates.
| Scenario | Hourly Rate | Total Hours | Total Cost |
|---|---|---|---|
| Low-end | $[X] | [hours] | $[X,XXX] |
| Average | $[X] | [hours] | $[X,XXX] |
| High-end | $[X] | [hours] | $[X,XXX] |
Recommended Estimate (Engineering Only): $[X,XXX] - $[X,XXX]
| Company Stage | Team Multiplier | Engineering Cost | Full Team Cost |
|---|---|---|---|
| Solo/Founder | 1.0× | $[X] | $[X] |
| Lean Startup | 1.45× | $[X] | $[X] |
| Growth Company | 2.2× | $[X] | $[X] |
| Enterprise | 2.65× | $[X] | $[X] |
Role Breakdown (Growth Company Example):
| Role | Hours | Rate | Cost |
|---|---|---|---|
| Engineering | [X] hrs | $[X]/hr | $[X] |
| Product Management | [X] hrs | $[X]/hr | $[X] |
| UX/UI Design | [X] hrs | $[X]/hr | $[X] |
| Engineering Management | [X] hrs | $[X]/hr | $[X] |
| QA/Testing | [X] hrs | $[X]/hr | $[X] |
| Project Management | [X] hrs | $[X]/hr | $[X] |
| Technical Writing | [X] hrs | $[X]/hr | $[X] |
| DevOps/Platform | [X] hrs | $[X]/hr | $[X] |
| TOTAL | [X] hrs | $[X] |
| Metric | Solo | Lean Startup | Growth Co | Enterprise |
|---|---|---|---|---|
| Calendar Time | [X] | [X] | [X] | [X] |
| Total Human Hours | [X] | [X] | [X] | [X] |
| Total Cost | $[X] | $[X] | $[X] | $[X] |
Estimated time savings with Claude Code: [X]% Effective hourly rate with AI assistance: ~$[X]/hour equivalent productivity
This is the most important metric for understanding AI-assisted development efficiency. It answers: "What did each hour of Claude's actual working time produce?"
Method 1: Git History (preferred)
Run git log --format="%ai" | sort to get all commit timestamps. Then:
Session Duration Heuristics:
Method 2: File Modification Timestamps (no git)
Use find . -name "*.ts" -o -name "*.swift" -o -name "*.py" | xargs stat -f "%Sm" | sort to get file mod times. Apply same session clustering logic.
Method 3: Fallback Estimate
If no reliable timestamps, estimate from lines of code:
Value per Claude Hour = Total Code Value (from Step 5) ÷ Estimated Claude Active Hours
Calculate across scenarios:
| Code Value Scenario | Claude Hours (est.) | Value per Claude Hour |
|---|---|---|
| Engineering only (avg) | [X] hrs | $[X,XXX]/hr |
| Full team equivalent (Growth Co) | [X] hrs | $[X,XXX]/hr |
| Full team equivalent (Enterprise) | [X] hrs | $[X,XXX]/hr |
Speed Multiplier:
Speed Multiplier = Human Dev Hours ÷ Claude Active Hours
Example: If a human would need 500 hours but Claude did it in 20 hours → 25× faster
Cost Efficiency:
Human Cost = Human Hours × $150/hr
Claude Cost = Subscription ($20-200/month) + API costs (estimate from project size)
Savings = Human Cost - Claude Cost
ROI = Savings ÷ Claude Cost
Add this section to the final report:
Project Timeline:
Claude Active Hours Estimate:
Value per Claude Hour:
| Value Basis | Total Value | Claude Hours | $/Claude Hour |
|---|---|---|---|
| Engineering only | $[X] | [X] hrs | $[X,XXX]/Claude hr |
| Full team (Growth Co) | $[X] | [X] hrs | $[X,XXX]/Claude hr |
Speed vs. Human Developer:
Cost Comparison:
The headline number: Claude worked for approximately [X] hours and produced the equivalent of $[X] in professional development value — roughly $[X,XXX] per Claude hour.
Present the estimate in a clear, professional format suitable for sharing with stakeholders. Include confidence intervals and key assumptions. Highlight areas of highest complexity that drive cost.
Remote control tmux sessions for interactive CLIs by sending keystrokes and scraping output.
Review a codebase, PR, or module for requirement fidelity, clean architecture quality, and production robustness. Verifies the change actually implements the stated requirement/user goal before checking structure, distinguishing design-level defects (right code, wrong product) from behavior bugs. Detects cross-layer business logic mixing, dependency direction violations, SOLID problems, module depth issues, information leakage, and KISS/over-engineering smells. Reports findings prioritized with SRE-style severity levels (P0-P3).
Practical guidance for writing, refactoring, and reviewing friendly Go code that is simple, idiomatic, and maintainable. Use whenever working with Go (.go) files, designing Go packages or APIs, structuring a new Go project, reviewing Go code, or refactoring Go modules. Also use when the user mentions goroutines, channels, context, error wrapping, interfaces, go.mod, package layout (cmd/internal/pkg), or Go project structure. Even if the user doesn't say "Go" explicitly, trigger this skill when the context involves .go files or go.mod/go.sum.
Validate and lint Agent Skill SKILL.md files and diagnose why a skill fails to load. Use whenever the user wants to check if a skill's frontmatter is valid, find out why a skill "vanished" or is not discovered, lint a single skill, or scan an entire skills directory before committing. Triggers on requests like "validate my skill", "why isn't my skill loading", "check the SKILL.md format", "lint my skills", "diagnose this frontmatter", or any request to verify skill name and description rules. Make sure to use this skill whenever a skill is unexpectedly missing from the available-skills list, since the usual cause is a silent frontmatter parse error rather than a discovery problem.
Write a grounded design/implementation doc for existing code, author a forward-looking design doc before code exists, or apply the embedded principles/checklist to review any design doc. Use whenever the user wants to understand, document, or reverse-engineer how a system, feature, or subsystem is architected (e.g. "how does X work in this repo", "document the Y subsystem", "reverse-engineer Z", "explain the design of W"), or wants to plan and write a new design doc before implementation (e.g. "write a design doc for X", "draft a design for this feature", "I need a design doc to coordinate this work"), or wants design-doc writing principles and a review checklist. Triggers on requests to analyze/document a system's internals, plan a new system's design, or review a design doc for completeness. Output follows a house format: prose + ASCII/Unicode/mermaid flowcharts, a key-file index, behavioral contracts, and a BDD scenario table, validated against checklist.md.
Guide a reverse-engineering proof-of-concept on a macOS crackme / license-check binary, for learning and interview preparation. Use this whenever the user is analyzing a app's authorization / license-gating module and wants to reconstruct its gating model, call chain, architecture differences (arm64 / x86_64 / universal Mach-O), and validate a minimal binary patch with LLDB and code signing. Trigger on mentions of crackme, license-check PoC, Mach-O / IDA / LLDB / objc_msgSend analysis, "find the gating branch", patch validation, universal binary slices, keygen-me vs patch-me, or CTF-style binary patching — even when the user does not say the word "skill".