Background & Context

Most freelance estimating advice comes down to "track your hours and multiply." That works if you bill hourly and your client has infinite patience but fixed-price quoting, scoping calls, and proposal writing demand a number before a line of code is written. Gut feel works fine on familiar projects. It fails badly on anything novel, complex, or under-specified.

COCOMO (Constructive Cost Model) is a decades-old software estimation technique that scales effort non-linearly with project complexity: larger, less familiar projects cost disproportionately more per complexity point. Its core insight, that a project twice as complex takes more than twice as long, is directly applicable to freelance work, but the original model was designed for enterprise software teams and doesn't map cleanly to solo or small-agency engagements.

This tool re-parameterizes COCOMO for the freelance context: 15 project archetypes, 35 feature modules, a three-level risk model, and calibration against the developer's own delivered-project history.

Problem Statement

The Question: How do you produce a defensible fixed-price quote for a web or software project before the work begins?

The Problem: Freelance estimates are usually either too optimistic (ignoring risk, revisions, and non-development hours) or too conservative (padding so aggressively that quotes become uncompetitive). Neither produces a number you can explain or defend to a client.

The Challenge: Any model needs to be simple enough to run during a scoping call yet rigorous enough to catch the factors that actually blow up projects, requirements ambiguity, timeline pressure, unfamiliar technology, and unlimited revision expectations. It also needs to improve over time rather than being static.

Methodology / Approach

The model has five stages, applied in sequence:

1. Complexity Points (CP): Each project type has a small/medium/large CP range drawn from a baseline table of 15 archetypes (landing page through design system). Feature additions contribute additional CP from a 35-item menu. An overhaul flag adds a fixed CP penalty for legacy codebase overhead.

2. Variable exponent: Effort scales as COEFF_A × CP^EXP_B. The exponent EXP_B is set by familiarity, 1.02 for expert-level technology up to 1.15 for first-time stacks, capturing the non-linear cost of working outside your comfort zone.

3. Effort Adjustment Factor (EAF): Three independent risk multipliers: requirements clarity (0.85–1.40), timeline pressure (0.95–1.30), and revision expectations (0.95–1.30); compound to produce the EAF. A "vague idea" brief with a rush timeline and unlimited revisions can push the estimate to 2.4× base.

4. PERT three-point range: Optimistic (×0.75), most likely (×1.0), and pessimistic (×1.60) scenarios feed a standard PERT formula, producing an expected E with a standard deviation. This is the number quoted to clients, not a single figure, but a range.

5. Cost and fixed-price quote: The range is priced at $50–$125/hr. The fixed-price quote uses (E + SD) × rate × 1.15; worst-case hours, highest rate, plus a 15% buffer, protecting the contractor on scope risk.

The phase breakdown (discovery 12%, development 62%, QA 18%, launch 8%) lets the tool produce a line-item proposal, not just a total.

Analysis and Findings

Four constraints shaped the design significantly:

Non-linear scaling must be visible. Early versions used a linear hour-per-CP multiplier. Testing against real projects showed that medium and large scopes were consistently underestimated. Switching to the exponential model, even with a modest EXP_B of 1.05 – 1.15, better matched actual delivery data and made the model explainable: "larger projects have more coordination overhead per unit of work".

Risk factors compound, not add. Treating requirements clarity, timeline, and revisions as additive penalties underweighted multi-risk scenarios. A project that's vague, rushed, and has unlimited revisions isn't 1.25 + 1.30 + 1.30 = 3.85× harder, it compounds: 1.25 × 1.30 × 1.30 = 2.11×. The current EAF is multiplicative.

The model needs feedback. Without calibration, COEFF_A defaults to 5.0, which is conservative enough to be safe but not personalized. The --calibrate flag opens a post-delivery intake that logs actual hours against the CP/EXP_B/EAF used. After five projects, the model re-computes COEFF_A as the mean ratio of actual hours to predicted base effort. The calibrated coefficient is stored as a CSV and syncs to the Claude Code new-project skill for inline use during scoping conversations.

Multi-type projects need a combo model. Some projects span multiple archetypes, a SaaS app that is also an integration platform, or a mobile app with a design system component. The model averages the base CP across selected types and adds a small combo bonus (2 CP per additional type) to account for the integration overhead between systems that don't usually talk to each other.

Solutions and Implementation

Browser Calculator

calculator.html is a self-contained, offline-capable HTML file with no external dependencies. It accepts all 13 intake parameters via a form and computes the full estimate on the client side. The browser tool supports multi-type project selection and the complete feature menu. It's designed for scoping calls: download once, open in any browser, never needs a server.

Conclusion and Lessons Learned

The core lesson is that estimation models work not because they're accurate, they're not, but because they're systematic. Forcing yourself to score requirements clarity, timeline pressure, and revision expectations before writing a quote makes you confront the risk factors you'd otherwise gloss over. The output number is less important than the process of producing it.

The calibration loop is the most underused feature. The default COEFF_A of 5.0 is a reasonable starting point for web development work, but it doesn't know whether you're a fast or careful worker, what your technology stack overhead looks like, or how your clients tend to behave in practice. Five delivered projects is a small sample but it's enough to shift the coefficient meaningfully and bring estimates closer to reality.

The fixed-price quote formula; worst-case hours, highest rate, plus 15%, is deliberately conservative. Fixed-price contracts transfer timeline and scope risk from the client to the contractor; the quote must price that risk in, not hope it away.

node estimate.js
node estimate.js --export        # also saves to ~/freelance-estimates/
node estimate.js --calibrate     # log actual hours after delivery

python3 estimate.py
python3 estimate.py --export

node estimate.js --calibrate
# enter: project name, CP used, EXP_B, EAF, actual hours