Todd Saunders posted about a /cost-estimate command in...
Todd Saunders posted about a /cost-estimate command in Claude Code that prices out what your codebase would've cost a real team to build. I liked the idea, turned it into a...
Todd Saunders posted about a /cost-estimate command in Claude Code that prices out what your codebase would've cost a real team to build. I liked the idea, turned it into a reusable skill, and pointed it at tonyseets.com.
Built a Reusable Cost-Estimate Skill
Todd Saunders posted this on X, showing off a /cost-estimate command that scans your codebase and cross-references current market rates to estimate what it would’ve cost a real team to build.
Got flooded with DMs asking for the markdown file.
Here it is, bookmark this.
---
name: cost-estimate
description: Estimate development cost of a codebase based on lines of code and complexity
---
# Cost Estimate Command
You are a senior software engineering consultant
Fun command built in Claude Code: /cost-estimate It scans your codebase and cross-references current market rates to calculate what your project would've cost a real team to build. It looks at all the APIs, integrations, everything. Without AI: ~2.8 years. ~$650k. With AI:
I liked the idea and wanted to run it myself. So I took a one-off prompt for pricing a codebase, turned it into a reusable local skill, and pointed it at this site.
The workflow is pretty simple:
- scan the repo and separate authored code from generated output
- read the architecture, build scripts, APIs, and tests
- look at git history to estimate active AI work sessions
- pull current US market-rate data and turn the whole thing into a budget and timeline estimate
Heads up: Everything below is AI-generated output. None of the numbers, estimates, or market-rate claims have been validated by me (Tony). Treat it as a fun exercise, not a real appraisal.
The number that stuck with me: about 57 AI-active hours produced something I’d estimate at roughly $496k of engineering value, or about $8.7k per AI hour.
What the skill found
I ran it against tonyseets.com, and the output was more useful than I expected:
| Metric | Estimate |
|---|---|
| Authored engineering code | 49.5k non-empty lines |
| Human rebuild estimate | 3,420 hours |
| Engineering-only cost | $496k-$650k |
| Growth-company build | $1.09M |
| AI-active time | 57 hours |
| Speed multiplier | 60x |
The interesting part wasn’t the final dollar number. It was where the cost actually sits.
From the outside, this still reads like a personal site. The estimate makes it obvious that the expensive part isn’t the pages. It’s the systems around them.
Where the cost actually lives
| System | Why it costs real engineering time |
|---|---|
| Content model | Keystatic schemas, editorial structure, data modeling |
| Runtime and security | Cloudflare integration, CSP automation, safer API surfaces |
| Build pipeline | search outputs, metadata generation, content transforms, machine-readable feeds |
| Tooling | GitHub activity sync, image-generation workflow, custom scripts |
| Product polish | interaction details, layout tuning, edge cases, responsive cleanup |
That is the part I like about this exercise. It makes the invisible work legible.
It is easy to ask an agent to build something and stop the conversation at “that was fast.” It is more interesting to ask what the finished repo would have cost to build the old way. Not because the estimate is objective truth. It isn’t. It is still a model sitting on top of a lot of assumptions.
But it does make the value easier to talk about.
It struck my curiosity, and I wanted to run it myself, so here it is.
The Skill
If you want the actual prompt, here is the shareable version I used:
---
name: cost-estimate
description: Estimate development cost, engineering effort, calendar time, staffing, and Claude ROI for any repository by auditing code size, architecture, specialized tech, git history, and current US market rates. Use whenever the user asks what a codebase cost to build, how many engineer hours or weeks it represents, what budget or team it implies, whether an MVP estimate is realistic, or wants a stakeholder-ready "how much is this repo worth / how much would it take to rebuild" report.
---
# Estimate Development Cost
Produce a professional estimate grounded in the actual repository, not a hand-wavy guess.
## What to deliver
- Default output: a stakeholder-ready Markdown report in chat.
- If the user asks for a file, save `<repo-name>-cost-estimate.md` in the repo root.
- Include explicit confidence, assumptions, and exclusions.
## Workflow
### 1) Start with a repo census
- Run `python3 ~/.codex/skills/cost-estimate/scripts/analyze_repo.py <repo-root>`.
- Use the JSON output as the quantitative baseline:
- LOC totals by language
- source vs tests vs docs vs config
- top files and top directories
- detected stack signals
- git timeline / Claude-hour estimate
- The helper script already excludes common generated and vendor directories. Call that out in the final assumptions.
### 2) Read the repo intelligently
- For smaller repos (`<= 60` relevant code files or `<= 15k` non-empty source+test lines), read all in-scope source, tests, build scripts, and docs.
- For larger repos, do a full inventory first, then read:
- top-level docs such as `README`, `CLAUDE`, architecture notes, roadmaps, phase docs
- build and config files
- entrypoints and the largest / highest-signal files in each subsystem
- test harnesses and representative tests
- If the repo has multiple independent subsystems such as app, backend, plugin, shaders, or infra, review those separately and synthesize the findings.
### 3) Turn code into human development hours
- Group work by subsystem and complexity instead of by language alone.
- Use these productivity bands as a starting point:
| Work type | Typical productivity |
| --- | --- |
| Simple UI / CRUD / straightforward web surfaces | 30-50 LOC/hr |
| Typical business logic / backend / data flows | 20-30 LOC/hr |
| Tests and automation | 25-40 LOC/hr |
| Build / infra / integration code | 15-25 LOC/hr |
| Native mobile / desktop framework code | 15-25 LOC/hr |
| C / C++ / FFI / system plugins / extensions | 8-20 LOC/hr |
| GPU / shaders / media / real-time processing | 8-20 LOC/hr |
| AI / ML orchestration or specialized APIs | 15-25 LOC/hr |
- Use the tables and formulas in `references/estimation-model.md` for overhead, organizational efficiency, and team multipliers.
- Estimate a range and a midpoint, not a fake-precise single number.
### 4) Research current market rates
- Browse for current rate data.
- Use at least 3 recent sources and include links.
- Search a baseline set:
- `senior software engineer hourly rate United States <year>`
- `senior full stack developer hourly rate <year>`
- `freelance <primary stack> developer rate <year>`
- `contract <platform> developer hourly rate <year>`
- Add stack-specific searches that match the repo.
- Prefer 2025-2026 US data.
### 5) Convert engineering hours into real-world delivery
- Use the efficiency table in `references/estimation-model.md` to show solo / lean startup / growth / enterprise calendar time.
- Use the team multipliers in `references/estimation-model.md` to show engineering-only cost and full-team cost.
- Include one concrete role breakdown, defaulting to the growth-company scenario unless the user asks for another.
### 6) Calculate Claude ROI carefully
- Prefer the helper script's git-session clustering output.
- If the helper had to fall back to file mtimes or LOC-based estimation, say so and lower confidence.
- Treat "Claude active hours" as a rough estimate of AI-assisted work time, not proof of authorship.
### 7) Final quality bar
- Anchor complexity claims to repo evidence.
- Anchor market-rate claims to current web sources with explicit dates.
- Keep the numbers internally consistent across sections.
- Highlight the top cost drivers.
- End with assumptions, exclusions, and confidence.