We audited 31 broken codebases. The same numbers keep coming back.

Every time Revin steps in to rescue a project, the first thing we do is read the code from the outside in. I pulled together what we found across 31 of those reviews over the last 18 months: test coverage, deploys, exposed secrets, who understands what. The sample is skewed on purpose, and that may be exactly why it's useful.

Por Raquel Reis

Raquel Reis

Every time Revin gets called in to rescue a project, the first thing we do is not write code. It is to read what is already there, from the outside in, the way a stranger would read it. That first read even has a name on our side, the Diagnostic Sprint, and over the last eighteen months it ran across a few dozen codebases. I sat down and added up what showed in thirty-one of them.

Before any number, the honest caveat: this sample is skewed on purpose. These are projects that reached us already in pain, and nobody hunting for a rescue is hunting for a compliment. So do not read this as "the average state of software". Read it as an x-ray of where things break when they break. Oddly enough, it is that biased cut that makes the pattern so easy to see.

If you are about to hire whoever builds or maintains your software, these four numbers are a decent checklist of what to ask before you sign. Not to distrust everyone, just to know where to look.

We don't start with the roadmap or the kickoff call. We start here: reading, line by line, what has already been built.

The four numbers

Here is what thirty-one reads gave back, with the figures rounded without apology, because a sample this size has no business carrying a decimal point:

• Test coverage: in 71% of the codebases, less than a fifth of the code had any automated test at all.
• Deploys: 6 in 10 relied on a manual deploy, run from one specific person's machine.
• Exposed secrets: 1 in 3 kept a production credential in plain text, committed to the Git history.
• Concentrated knowledge: in 22 of the 31, more than half the system was truly understood by a single person.

None of these numbers is exotic. Each one, on its own, is the kind of corner you can wave away with a "we'll fix it later". Together they tell a different story, and that story is the one worth telling.

What the numbers don't say on their own

Low coverage is rarely laziness. It is what is left over when someone is paid to ship screens and nobody is paid to make sure the screen still stands six months from now. Tests do not show up in the demo. A clean deploy does not either. What shows up is the next feature, and that is where the vendor's money is.

The manual deploy is my favorite on the list, because it is almost always the same scene. In one audit, of an e-commerce business doing seven figures, the production deploy was a script run from one developer's laptop. A laptop that went home with him every night and to the beach on holidays. When that developer took time off, the company effectively froze. Nobody had decided it would work that way. It just drifted there, sprint after sprint, with no one watching.

This is exactly the kind of thing the Diagnostic Sprint puts on the table in two weeks, before it turns into a crisis. And for the number people, we had already published a benchmark on PR review time in the same spirit of measuring what tends to stay invisible.

The secret nobody had rotated

That 1 in 3 with a credential in the open is the number that scares the client most when it appears on screen, and the one that surprises us least. The key goes into the code in a rushed commit, it works, and it stays. Nobody rotates it because nobody remembers it is there. I wrote last week about why this is a habit rather than bad luck, in security isn't a feature, it's how the team works.

The numbers only become a diagnosis when someone stops to look closely. That is literally the job.

The pattern behind the damage

Looking at the thirty-one together, what they share is not a technology, not a sector, not an incompetent team. Almost everyone involved was good at their job. What they share is the model behind the build: software made by people who were paid for delivery and then left. The freelancer who ran for three months and vanished, the agency that closed the scope and never came back, the vendor who swapped developers without handing over context. Nobody stayed long enough for the house to matter after they moved out.

That is precisely the gap an embedded squad fills, and not through greater talent. It is through staying. When the team that writes the feature is the same one maintaining it a year from now, the test stops being a cost and becomes self-preservation. The manual deploy, likewise: nobody wants to run by hand, every week, something they could automate once. And that secret in the repo becomes the problem of someone who will still be around when it leaks. Continuity changes the incentive, and the incentive changes the code.

In the end, what struck me across these thirty-one reads was not how severe any single case was. It was the repetition. The same four holes, in different orders, project after project. And something that repeats this much is not luck, it is structure. Structure can be predicted, and what can be predicted can be avoided.

If you want to see this pattern being undone in practice, the cases tell it better than I can. And if you suspect your own codebase is hiding two or three of these numbers, it is far cheaper to find out now, with us, than in the middle of a crisis. Whenever you like, book a call.