What you have
A product that earns, several years of code, and a team small enough to name
For companies whose code is older than the team
Small team. Large legacy.
The product has been earning for years. Most of the people who wrote it have gone, and what they knew went with them. What is left is more code than anyone here can hold in their head, a release that needs someone on standby, and a list of changes the business keeps asking for that keeps not happening. That is a different problem from a product built last spring, and it is the one this page is about.
The teardown is a document, not a sales call. You do not have to buy anything after it.
Teardown · · v1
cost $0
What breaks first, at what load, and what it costs
What we readThe running code, files
What we could not seeProduction data, one private module
VerdictOne month is enough for a named part
What we could not see. Production data and the module. Every finding that rests on them is marked ASSUMED below. This list comes before the findings, not after.
Finding 1 · MEASURED. The order queue and the share one database connection. Under the webhook times out and an order is charged twice. Reproduced on . Fix: , days.
Finding 2 · READ. is traced in the code but was not run. Cost when it fails: .
Evidence: MEASURED = we reproduced it · READ = traced in the code, not run · ASSUMED = rests on what we could not see
The situation, in five lines
What changed
Every change costs more than the last, and nobody can say precisely why
What you get offered
A rewrite, or a hire who needs a year on this codebase before he is useful
What we do
Read what runs, write down what actually breaks, then hold one part of it up for a month
Price
Fixed, named after the teardown · one month · teardown $0
Answer these without us
Four questions you can answer without us
None of these need a meeting, and none of them need our opinion. Answer them for yourself. They are the four that decide whether there is anything here for you.
01
Is there a part of the system exactly one person can safely change — and does everyone already know which part, and which person?
02
When did someone last upgrade a dependency on purpose, rather than because something forced it?
03
If the test suite went red tonight, would anyone believe it — or would the first move be to check whether the tests are broken again?
04
How long does a change the business calls small actually take, from asked to live? Not the estimate. The last three.
If three of those landed, a teardown will tell you something you do not already know, and it costs you nothing to find out. If none of them did, you are in better shape than most and you probably do not need us.
The alternatives · both expensive
The two answers you have already been given
Everyone with an old codebase has heard both of these, and both are honest answers from the people who give them. They are also the two most expensive ways to find out whether they were necessary.
Start again
Rewrite it, on a stack someone can hire for. It is priced in quarters and paid in full before any of it earns, and for the whole of that time the thing that pays your salaries is on maintenance and nothing new ships from it. Sometimes it is the right call. It is never the cheap way to discover that it was not.
Hire someone senior
One good engineer, permanent. He will be useful on this codebase in six months to a year, because that is how long an undocumented system takes to learn, and the knowledge he builds walks out with him if he leaves. The salary is not the expensive part. The year is.
What both skip
Neither answer begins by measuring anything. Both are quoted from a conversation about your code rather than from your code. A rewrite quote is an opinion about a system the person quoting it has usually never run.
What we saw once
One founder had two engineering shops read his product, and both came back with the same answer: start again from zero. He did not, and one month later it carried the load his new customer brought, with nothing rewritten. That is one client's experience, n = 1, and not an industry average. The whole of it is on the main page.
Why the licences did not help · it cuts both ways
Why the AI you bought for the team did not fix this
You bought the licences. Everyone did. On a young codebase they show up as speed within a week; on a large old one they mostly show up as more code to review, and it is worth being precise about why.
What actually happens
An agent given a codebase it cannot hold at once writes plausible code in the local style — including the parts of the local style that are the problem. The volume of change goes up. The ability to review it does not. On a system with no release check, that is not speed; it is the same accumulation as before, arriving faster.
The other half of it
The same tools made one kind of work cheap for the first time, and it happens to be exactly the work an old codebase needs: reading all of it, writing the tests that were never written, doing the mechanical sweep across hundreds of files. That used to be priced in engineer-months, which is why nobody ever authorised it. Under review, it is now the part agents are genuinely good at.
What is missing between the two
A release check, and someone senior deciding what is worth doing at all. Without those, more capacity makes an old system worse faster. With them, a month reaches further into a codebase than a month did three years ago. That is not a slogan — it is the arithmetic our price depends on.
Scope · does four things, does not do four
What one month does to a large codebase, and what it does not
A month does not undo years, and we are not going to pretend otherwise on the page where you decide whether to write to us. Here is the whole of both lists.
What the month does
- the map. What is there, what actually runs, and what nothing depends on any more — with an evidence class on every finding, so you can see which parts we measured and which we only read.
- the release check. From that week on, every change goes through tests and a review before it ships. This is the part that stops the codebase getting worse while we are still reading it.
- one dangerous part, made safe. The one the teardown ranks first: tests around it, the change made, and a measurement before and after. One part done properly, named in advance, rather than a light touch on twelve.
- the method, left behind. The tests, the release checks, the delivery setup, the written notes, and the agents we ran the month with — configured for your codebase, in your repository, yours to keep running.
What it does not
- rewrite it. Nothing is rebuilt from zero. If the teardown concludes that a rewrite is genuinely the right answer, it says that, and then we are not the people you need.
- cover every module. A large codebase gets one honest pass and one part finished. Anyone promising full coverage of years of code in four weeks is selling the promise, not the work.
- replace the people who left. It writes down what only they knew, wherever we can recover it from the code. That is worth having, and it is not the same thing as having them back.
- continue by itself. The exit date is agreed before the first invoice. There is no retainer and nothing renews. If you want a second month later, that is a second decision, made with the first one already delivered.
One part finished beats twelve parts touched. On an old system the difference is the whole result.
The report · free · three possible verdicts
What the teardown looks like on a codebase this size
It is a written document, not a call and not a slide deck. On an old system the honest parts of it are the ones about what we could not see, and those come first rather than last.
What we read, and what we could not
It opens with the repository, the commit and the size of what we read — and then with the list of what we had no access to: the production data, the traffic, the parts behind credentials we were not given. Every conclusion resting on something we could not see is marked as resting on it.
An evidence class on every finding
MEASURED means we reproduced it and the run is described. READ means we traced it in the code but did not execute it. ASSUMED means it follows from something we could not see. None of the top three findings is ever allowed to be ASSUMED.
Numbers, not adjectives
Each finding names where it lives, the load it breaks at, how far that is from today, what it costs when it happens, the fix in one sentence, and the days that fix takes. No severity adjective appears without a number beside it.
Three verdicts, and one of them is no
A month is enough; a month is enough for a named part of it; or a month is not enough and here is what would be. The third is a real outcome. It ends with a document you keep and an invoice that never arrives.
Yours, including against us
You own the document. Hand it to your board, to your own engineers, or to the shop that quoted you the rewrite — including as the list of questions to put to them. We claim nothing over it.
Price and terms
What it costs.
If the teardown shows that you do not need us this quarter, we write that in the report. This has happened before.
Teardown
Free
a written report, not a sales call
- We read the running code, not a questionnaire
- What breaks first, at what load, what it costs
- Yours to keep. You can give it to any engineer, including the ones you hire instead of us
One month
Fixed
the price is named in the teardown
- We name the price only when we know one month is enough
- We agree the end date before you pay
- No retainer. Nothing renews. Nothing is rebuilt from zero
This page describes a situation, not a client. The one engagement referred to above is the case published in full on the main page, at n = 1, with the founder and his customer unidentified at his request.
Three fields · no sales call
Ask for the free teardown.
Roman or Ivan reads your message, not a mailbox. If we need access to your repository to write something useful, we ask for it in our first reply and say exactly what we need.
Or email rv@system5.dev. Your name, your email, and the one thing you are most afraid will break. That is enough.
We have it.
Roman or Ivan reads it, not a mailbox. If we need access to your repository to write something useful, we ask for it in our first reply and say exactly what we need.
If the teardown shows that you do not need us this quarter, we write that in the report.
Questions we hear from an old codebase
Five answers.
Every answer below is also in the structured data of this page, word for word.
Our code is not public and we cannot hand a repository to strangers.
We sign a non-disclosure agreement before you send anything, and read-only access to a copy is enough. If you cannot share code at all, we cannot write a teardown worth reading, and we will tell you that rather than sell you a call instead.
Nobody here has time to brief you.
The three fields on this page are the brief. If the teardown needs more, we ask one round of questions in writing, and we ask them once.
What if one month is not enough for a codebase this old?
Then the teardown says so, and names what would be. That is one of the three verdicts the document can reach, and it is the one that ends with us not taking the money.
What happens to the agents when you leave?
They stay. They are configured for your codebase and they sit in your repository, along with the tests, the release checks, the delivery setup and the written notes. We leave on the agreed date and nothing renews by itself.
Is the teardown an audit?
No. It is an opinion formed from reading code, in the time we spent reading it. It is not an audit, not a certification and not a security assessment. If what you need is a certified audit, we are the wrong people and we will say so.