Cost Estimate

Estimate what it would cost a competent team to build, replace, or meaningfully advance the current codebase. Produce a professional report grounded in measured repository facts, explicit assumptions, and current market rates.

Core Rules

Stay Generic

• Analyze the actual repository instead of assuming a specific stack, language, or company shape.
• Use the file-reading, search, counting, git, and web-research tools available in the current agent environment. Do not depend on tool names from a single platform.
• Support repositories built mainly by humans, mainly by AI agents, or a mix of both.

Separate Facts From Inference

• Distinguish measured facts from judgment calls.
• Exclude obvious vendor code, generated artifacts, caches, lockfiles, build outputs, and bundled dependencies from primary LOC counts unless the user explicitly wants them included.
• Report uncertainty with ranges and a confidence level instead of pretending the estimate is precise.

Workflow

1. Scope the Estimate

• Determine whether the user wants the full repository, the shipped product surface, an MVP subset, or a specific subsystem.
• Identify the current maturity level: prototype, internal tool, beta, production system, or partially complete implementation.
• Note what appears finished, what appears missing, and what would still need to be built for the requested target state.

2. Inventory the Codebase

• Count non-generated lines of code by major language or layer.
• Review architecture, module boundaries, dependencies, integrations, deployment surface, testing, and documentation.
• Flag complexity drivers such as:

- native/mobile development, - security-sensitive or regulated workflows, - real-time systems, - graphics, rendering, audio, or video pipelines, - distributed systems or infrastructure automation, - data engineering or ML/AI integrations, - third-party APIs with operational risk, - migrations, legacy constraints, or platform-specific interop.

• Summarize test depth and delivery confidence:

- automated tests, - CI or release automation, - observability and operational tooling, - docs and onboarding quality.

3. Convert the Repo to Engineering Hours

• Start with low, base, and high estimates instead of a single point estimate.
• Use broad productivity buckets that work across languages:

- straightforward UI, CRUD, or glue code: 30-60 lines/hour, - standard product and business logic: 20-40 lines/hour, - infrastructure, data, platform, security, or performance-critical work: 10-25 lines/hour, - specialized systems work such as native interop, rendering, low-level networking, device integration, or real-time media: 8-20 lines/hour, - comprehensive automated tests: 25-50 lines/hour.

• Adjust for non-coding work:

- architecture and design: +10-20%, - debugging and troubleshooting: +15-30%, - review and refactoring: +10-15%, - documentation and handoff: +5-15%, - integration, QA, and release hardening: +15-30%, - learning curve for unfamiliar or niche technology: +5-20%.

• If the repo is obviously incomplete, estimate both:

- replacement value of what exists today, - total effort to reach the likely intended scope.

4. Convert Raw Engineering Hours to Calendar Time

• Explain that raw development hours do not equal calendar time.
• Model at least these execution environments:

- solo or founder-led, - lean startup, - growth-stage company, - enterprise team.

• Use realistic focused-coding efficiency factors such as:

- 60-70% for lean environments, - 50-60% for growth-stage teams, - 40-50% for enterprise teams, - 30-40% for highly process-heavy organizations.

• Show calendar impact in weeks or months using:

Calendar Time = Raw Engineering Hours / Effective Engineering Hours Per Week

5. Research Current Market Rates

• Use current web research when available. Prefer recent sources and include concrete dates.
• Look up rates relevant to the project's stack and the estimate's audience, such as:

- senior full-stack or platform engineers, - specialized domain engineers relevant to the repo, - US remote, SF Bay Area, NYC, Austin, or other requested markets, - contractor, consultancy, and employee-equivalent comparisons when useful.

• Use primary or reputable market sources and cite them in the report.
• If live research is unavailable, say so and clearly label rate assumptions as lower confidence.

Suggested search patterns:

"senior software engineer hourly rate <year>"
"freelance <stack> developer rate <year>"
"software development consulting rates <year>"
"<specialty> contractor rate United States <year>"

6. Calculate Full Team Cost

• Do not present engineering-only cost as total product cost unless that is explicitly what the user asked for.
• Model supporting roles as ratios to engineering effort when appropriate:

- product: 0.20-0.40x, - design: 0.15-0.35x, - engineering management: 0.10-0.20x, - QA: 0.15-0.30x, - project or program management: 0.05-0.15x, - technical writing or enablement: 0.03-0.10x, - DevOps or platform: 0.08-0.20x.

• Provide a team multiplier for at least:

- solo: 1.0x, - lean startup: about 1.3-1.6x, - growth company: about 1.8-2.3x, - enterprise: about 2.2-2.8x.

7. Add Optional AI-Agent ROI Analysis

• Include this section only when the user asks for it or when the repository appears to have been produced substantially by an AI coding agent.
• Use the agent label that best fits the evidence or request:

- Claude, - Codex, - OpenCode, - Crush, - AI coding agent when the brand is unclear.

• Estimate active agent time using one or more of:

- git commit clustering, - file modification clustering, - issue or PR history, - fallback LOC-based heuristics when timestamp evidence is weak.

• Keep the assumptions explicit. Do not imply precise time tracking when only heuristics are available.

Useful heuristics:

Session clustering window: 3-4 hours
1-2 commits in a session: ~1 hour
3-5 commits: ~2 hours
6-10 commits: ~3 hours
10+ commits: ~4 hours
Fallback AI-agent active hours: meaningful LOC / 250-500

• Calculate:

Value per Agent Hour = Estimated Human/Team Value / Estimated Agent Active Hours
Speed Multiplier = Estimated Human Hours / Estimated Agent Active Hours

8. Write the Report

• Write for stakeholders, not just engineers.
• Include:

- analysis date, - scope and maturity, - codebase metrics by language or subsystem, - major complexity drivers, - engineering hours with low/base/high ranges, - calendar-time scenarios, - market-rate research, - engineering-only cost, - fully loaded team cost, - assumptions, exclusions, and confidence, - optional AI-agent ROI.

• Make the headline numbers easy to scan.
• Include a short narrative explaining what most drives cost.

Example Usage

"Use $cost-estimate to estimate what it would cost a US-based team to rebuild this repo to production quality."

"Use $cost-estimate to produce a stakeholder-facing budget range and calendar estimate for this MVP, including a lean-startup and enterprise scenario."

"Use $cost-estimate to estimate the value created by Codex in this repository and compute ROI per agent hour."

Best Practices

• Prefer ranges over false precision.
• Keep engineering cost and full-team cost separate.
• Call out whether the estimate reflects current code only or the likely complete product scope.
• Cite current rate research with dates.
• Reconcile LOC with architecture and operational complexity instead of using LOC alone.

Common Pitfalls

• Treating generated code or vendored dependencies as core product effort.
• Quoting hourly rates without geography, specialty, or year context.
• Ignoring non-coding time such as design, debugging, integration, and release hardening.
• Presenting AI-agent ROI as exact when it is based on heuristics.