One command, on your own machine, right now
Ancient Code is free and open source. It reads the repository you point it at and prints what it found. No account, no upload, nothing installed permanently, no configuration.
$ npx ancient-code . # the five measured questions, on your repository $ npx ancient-code . --report # the same thing as a page you can forward
That is the same command that produced every number in the four public reports on this site. The sixth question, who holds the keys, is answered by a person and the report says so rather than printing a confident guess.
Needs Node 20 or newer and a full clone, because ages come from git history. In a shallow clone git dates every line to the day it was fetched, so the report says the age was not measured rather than printing a confident zero.
Just the scaffolding question
ancient-fences answers one of the five on its own, and ships inside the first. Use it when that is all you want.
$ npx ancient-fences . # what is standing in this codebase $ npx ancient-fences . --check # and whether those reasons still hold $ npx ancient-fences . --tasks # the dead ones, written as work for your agent
Your code never leaves your machine. The only network call in either tool is asking a public tracker whether an issue is still open, and only when you pass --check.
The oldest one in webpack's source, in full: a comment in lib/UseStrictPlugin.js explaining why the code strips a "use strict" it will put back later, with a link to webpack's own issue #1970. That line has not been touched since February 2018. Nobody has had a reason to look at it since, which is exactly why nobody has checked whether the reason still holds.
Both projects are maintained by excellent engineers. That is exactly the point: this is not negligence, it is blindness that nothing on the market corrects.
Findings in tests are counted separately and never listed as work. A comment in a test that links to an issue is usually the regression test for that bug, so a closed issue there is a reason to keep the test, not to delete it. eslint has 399 of those next to 43 in its source, and one number for both would have made it look ten times worse than it is.
The scanner does not edit your code. Knowing that a fence is dead is the scarce part, and every editor already ships something that can do the deleting, so the findings come out as work for whatever agent your team already uses, with the test suite as the safety net.
Dependency creeps up on you one quote at a time
Nobody signs up for lock-in. It arrives over years: a system grows, the people who built it are the only people who understand it, and one day a quote arrives that feels wrong, but you have no way to say why, and no way to leave.
The asymmetry is not about honesty. It is about memory. Your vendor remembers everything they built for you. You remember the invoices. That gap is the whole problem, and it widens every year.
A quote arrives
90 hours for a module you suspect was rebuilt twice already. You need the history, before the meeting.
The contract is up
The one moment you have leverage. Also the one moment you need facts rather than a feeling.
You are considering a change
Before you can price a new vendor, you need to know what handing this over actually costs.
Someone is buying your company
Their technical due diligence will ask exactly these questions. Better that you asked them first.
Six questions, five of them measured
Each one is a fact about your repository that a machine can check and anyone can re-check, rather than an opinion about somebody's work. Here they are on a repository you already know.
Transferability
webpack/webpack · measured 2026-08-31
How many people understand each part?
Measured from authorship history, not from a staffing plan.
Is there a safety net for changes?
Automated tests and checks: whether a change in one place is caught before it breaks another.
How much of it is scaffolding nobody removed?
Workarounds still standing after the problem they were built for was fixed. Measured by Ancient Fences.
Does it build from scratch?
What the repository declares about its own toolchain, dependencies and build steps.
Is the documentation real?
Whether a new team could deploy, restore a backup, and rotate a secret by reading it.
Who holds the keys?
Domains, servers, certificates, app-store accounts, payment credentials.
Nothing above is a sample. It is the output of npx ancient-code . on a full clone of webpack, and it changes when webpack changes. That is the point of measuring rather than judging: the number moves, and you can see which question moved it.
Not an accusation. A memory.
Ancient Code will never tell you a price is unfair. Nobody can measure that honestly, because most of the work is thinking rather than typing, and a three-line fix can legitimately cost forty hours.
What it does is give you back the memory your vendor already has. You stop guessing and start asking the right question.
webpack/webpack · the four busiest areas · last three years
Before a quote, this is the history of the area it touches.
This tool counts changes and people, never hours or money: it cannot see an invoice and does not pretend to. What it gives you is the question. If an area was already rebuilt twice by one person, that is worth knowing before you agree the next quote, and a vendor doing good work can now answer it in one sentence instead of an argument.
Why good vendors like this
A serious software house is losing bids to cheaper shops that deliver something that looks the same and rots in two years. This gives them evidence: the tests, the documentation, the fences they cleaned up.
They are also the ones who will happily sign a contract clause about it, because they already meet it.
Framed as your contract, not a trial
The strongest use is the least confrontational one: your agreement says you receive documentation and code that builds. Ancient Code shows whether that is true, as often as you care to run it.
That is compliance with something both sides signed, rather than a judgement of anybody's craft.
Your vendor holds the repository
This is the real obstacle, so let us be direct about it. There are three ways in, in order of how well they work:
You already have access
More often than clients think. If the code is in your organisation's account, or your contract gives you a copy or an escrow deposit, nothing needs to be renegotiated. Read access is enough; Ancient Code never writes.
At renewal
The moment you have leverage. A clause on documentation, buildability and code hand-over is standard, cheap to agree, and a vendor who refuses it has told you something valuable for free.
As a joint dashboard
Proposed to both sides at once, with the vendor seeing the same numbers you do. Slower to set up, and by far the most durable. It turns an audit into a shared instrument.
What Ancient Code is not: it does not monitor individual developers, rank them, count their hours or read their messages. It looks at what was delivered and what state it is in. The unit of measurement is the codebase, never the person.
What people ask first
Will this damage the relationship with my vendor?
It depends entirely on how it is introduced. Contract compliance and hand-over readiness, shared with the vendor, is a very different conversation from a secret audit. Every measurement is a fact about the codebase, and a vendor doing good work comes out of it looking good, with proof they could not produce before.
Can it tell me whether I am being overcharged?
No, and any tool that claims otherwise is selling you a false accusation. It tells you what you have already paid for in the area a quote touches, how big past changes there were, and how the system's state has moved. You draw the conclusion, with facts on the table.
Do we need to be technical to read it?
Running it needs somebody with a terminal and a clone of the code. Reading it does not: the output is six plain questions with a one-line answer each, and --report turns it into a page you can forward to whoever signs the invoices.
What does it cost?
Nothing. Both tools are MIT-licensed and run locally, and there is no paid tier hiding behind them. Nothing is held back for a version you have to buy: the command on this page is the whole measurement.
How long does it take to run?
Seconds to minutes, depending on the size of the history. webpack, one of the larger repositories on this page, takes under a minute on a full clone. The slow part is the git history, not the scan.
What if our system is old and messy?
Then you are exactly who this is for. A two-year-old project has little to find. Ten-year-old systems with several vendors in their history are where the numbers are ugly and the money is real.
Find out what leaving would cost, before you need to know
Run npx ancient-code . on any system you own or can clone. Five of the six questions are answered on your own machine, in one command, on evidence anyone can re-check.
The sixth needs a person. Who holds the domains, the servers, the certificates and the payment credentials is a question about your organisation, not about your repository, and no scanner should pretend otherwise. If that is the conversation you need to have about a system somebody else wrote for you, write to me.
One line to hello@ancientcode.net is enough. No form, no newsletter, no tracking on this site.