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 you
Their technical due diligence will ask these questions. Better that you asked them first.
A transferability report, every quarter
Six questions, each measured rather than judged. Every one of them is a fact about your repository that a machine can check and a court could verify, rather than an opinion about anyone's work.
Transferability
Sample report · repository: orders-platform
Does it build from scratch?
Clean machine, only the repository and the written instructions. Nothing from anyone's laptop.
Who holds the keys?
Domains, servers, certificates, app-store accounts, payment credentials.
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.
Is the documentation real?
Whether a new team could deploy, restore a backup, and rotate a secret by reading it.
How much of it is scaffolding nobody removed?
Workarounds still standing after the problem they were built for was fixed. Measured by Ancient Fences.
The estimate is a range with its workings shown, not a verdict. What makes it useful is not precision. It is that the number moves, and you can see which of the six questions 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.
Quote received · payments module · 90 hours
This area has been rebuilt three times. Here is what you paid for it.
Nothing here says anyone did anything wrong. Rebuilding three times can be entirely justified, and if it is, your vendor can now show it in one sentence instead of an argument. That conversation is the product.
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 every quarter whether that is true.
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.
Start with the part that costs nothing
Ancient Fences is the open-source front door: it finds code written because of someone else's bug, then checks whether that bug is still there. One command, no signup, MIT licensed. It is one of the six measurements above, given away whole.
$ npx ancient-fences . # what is standing in this codebase $ npx ancient-fences . --check # and whether the reasons still hold $ npx ancient-fences . --report # a report you can forward to whoever pays $ npx ancient-fences . --tasks # the dead ones, written as work for your agent
One command, no signup, nothing installed permanently. It reads the repository you point it at and prints what it found.
The oldest one in webpack, in full: a workaround written in November 2017 pointing at a bug in UglifyJS, a library webpack replaced in 2018 and which no longer appears in its dependencies even once. The issue is closed. The fence still stands, in a directory named after its replacement.
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.
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.
What people ask first
Will this damage the relationship with my vendor?
It depends entirely on how it is introduced, which is why we hand you the framing: contract compliance and hand-over readiness, shared with the vendor, never 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?
No. The report is written for whoever signs the invoices: six plain questions, an estimate of hand-over cost in months, and what changed since last quarter. The technical appendix is there for your engineers or your next vendor.
How long does the first report take?
Days, not weeks, once read access exists, most of the measurement is automated. The slow part is agreeing access, which is why the contract framing matters more than the technology.
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
The first report is a fixed-scope engagement on one system: six measurements, the hand-over estimate, and the evidence pack for your next quote.
Or write directly to hello@ancientcode.net.