Methodology

What we estimate

Every result is an Estimated Professional Rebuild Value.

Both assumptions matter. Nobody has to discover what to build — the product already exists and can be observed. And nobody is rebuilding it the slow way; the team doing the work has the same tools available to it that you do.

We value capability, not code volume

The estimate is driven by what the software does: its capabilities, the workflows it supports, the services it integrates with, the permissions it enforces, how it behaves with data, and how it is put together.

Lines of code are descriptive. We report the size of your codebase because it is a fact about it, but volume is not a multiplier. A large, repetitive application can be cheaper to recreate than a small one doing something genuinely difficult, and an estimate that failed to say so would be measuring typing rather than engineering.

Duplication, boilerplate and over-engineering earn nothing.

Modern software development

AI-assisted development has materially changed engineering productivity. It has not changed all of it equally, and the evidence for how much it changes is more mixed than the marketing suggests.

Straightforward implementation compresses dramatically — ordinary screens, forms, standard endpoints, framework wiring, conventional dashboards. Integration, verification, and work inside a complex existing system compress much less. Getting something to work is faster than knowing it works.

That is why we estimate a modern rebuild directly, rather than estimating the traditional cost and applying a fixed “AI productivity multiplier” to it. No single multiplier survives contact with the evidence, so we do not pretend one exists.

What professional delivery includes

We are estimating a commissioned rebuild, not a prototype. The effort covers implementation, testing, integration, security, deployment, verification and handover — everything between “it works on my machine” and software a team could responsibly hand to you and walk away from.

That is the difference between the number on this page and what you might spend on a weekend.

How the estimate is produced

Three stages, deliberately separated:

1. Your repository is cloned into an isolated temporary worker and measured. This stage counts things; it does not form opinions.
2. Those measurements, plus a redacted selection of source, go through an AI-assisted engineering assessment that identifies what the product does and estimates the effort to rebuild each capability. It returns hours and reasoning. It is never asked for, and cannot return, a monetary figure.
3. Those hours are multiplied by one published reference rate. That arithmetic is deterministic: the same assessment always produces the same number.

The reference rate

A single blended professional commissioning rate — what it costs to have a competent team deliver an hour of production-ready work, not a developer’s salary. It is applied uniformly, and is not adjusted for your location, your seniority, or how you actually built the software.

It is an estimate, and it has a range

Every result carries a range, and the range is the honest part. It widens where we could see less: a smaller sample of your source, an unusual stack, behaviour that only shows up at runtime, decisions you made that left no trace in the code.

Two runs against different commits will differ, and the assessment contributes some variance of its own. Treat the headline as the middle of a range, not a quotation. Anyone who gives you a single precise number for this is guessing more confidently than the problem allows.

What this is not

This is not a valuation of your company, and it is not what anyone would pay for your business. It excludes:

• revenue, profit and unit economics
• your customers, contracts and pipeline
• brand and reputation
• distribution and market opportunity
• the value of your equity

Software that would be expensive to rebuild can be worth nothing commercially, and a valuable business can run on software that is cheap to recreate. These are different questions. We answer one of them.

What informed our approach

Software cost estimation is an old discipline with a serious literature. AI-assisted development has produced a much newer one that, read honestly, disagrees with itself. Both shaped how we frame the question:

• IFPUG Function Point Analysis — the long-standing practice of sizing software by the functionality it delivers rather than by the volume of code that delivers it. It is why we count capabilities.
• Carnegie Mellon’s Software Engineering Institute on cost estimation, and the COCOMO tradition — cost drivers such as complexity, reuse and the required quality bar, together with calibration against real delivered work, matter more than raw size.
• SEI’s work on cost uncertainty — early estimates are ranges. Presenting one as a precise figure is itself a failure mode.
• The GitHub and Microsoft controlled experiment on Copilot (2023) — on a bounded, well-specified task, developers with an AI assistant finished around 55% faster. Contained work can improve enormously.
• Google’s randomised controlled trial on developer productivity (2024) — on enterprise work, a real but far more moderate gain, on the order of 20%, with wide uncertainty around it.
• METR’s 2025 study of experienced open-source developers — working on their own mature repositories, developers were around 19% slower with AI tools, while believing they had been faster. The effect varies by repository, by task and by developer, and it is not always positive.
• DORA’s State of AI-assisted Software Development — faster coding does not automatically become faster or more reliable delivery. Writing the code is one part of shipping software.

We have deliberately not cherry-picked the flattering results. Taken together this work does not support a single “AI makes engineering N times faster” figure — which is precisely why we estimate a modern rebuild directly, task by task, and publish a range around it.

This research informed our principles. It does not mathematically produce your valuation. There is no published formula here into which a repository is fed and a number falls out. Your estimate is a judgement about your specific software, made under the principles above, and it should be read as one.

What “repository verified” means

Only this: the analysis was produced from the stated repository at the stated commit. It is a statement about provenance, not accuracy. The valuation remains an estimate.

Versions

Every analysis stores the versions that produced it, so an old result stays interpretable after we change how this works. A completed result is never silently repriced.