
Victhor Araújo
I opened that edtech’s repo on a Saturday night chasing a dumb bug: the password-reset email was not reaching a slice of users. I grepped for "sendMail". Three results came back. Not three calls to the same function, three different functions, in three different files, each sending email its own way.
The codebase was three years old and had seven freelancers in its git history. I counted them by the names on the commits, half out of curiosity, half out of dread. Seven people had come through, and each one, at some point, needed to send an email and decided to write it fresh instead of looking for what was already there. The edtech had just signed with Revin, and this was the first thing I saw.
If you are a founder who hired freelancer after freelancer to run the product, each one great on paper, each one referred by someone, this piece is about your codebase, even if you have never opened the git log.

I searched for one email sender and found three, each written by a different hand that never read the other two.
I fixed the password-reset sender in twenty minutes. The catch was that the signup-confirmation email used a second of the three senders, and that one stayed broken for another week, until a user complained to support. Billing used the third. Three places to fix the same thing, and nobody on the team knew there were three.
That is the cost duplication hides, and it is not disk space. It is a fix that should cover the whole product covering only one slice, while the other two stay broken without telling anyone. You think you solved it. The customer finds out you did not.
The uncomfortable answer is that deleting code is work and it does not show. When a freelancer comes in to ship "the billing flow in two weeks", they have two weeks and a locked scope. Reading the other thirty files to discover there is already a half-finished mailer is not in their budget. Writing a new one they control and understand is faster and safer for the deadline. So they write it.
None of the seven did it out of laziness. I read their code; there were some very good people in there. They ran the math any sensible freelancer runs: reusing someone else’s code you do not understand is riskier than writing from scratch, when you leave in two weeks and never come back. It makes sense for each of them, in isolation. What nobody adds up is the effect of the seven combined.
And here is a concession I owe, or I would be lying by omission: a freelancer is not the villain in every case. For a campaign landing page, a script that runs once, an isolated integration nobody will touch again, hire a good freelancer and be happy. The damage shows up when you use serial freelancers to build and maintain a product that depends on continuity. Every handoff resets the system’s memory to zero.
Add it all up and the bill left for the founder has four lines, none of which appeared in any of the seven contracts:
That CSV, when I added up the hours logged to rebuild what already existed, came to about 26,000 reais, a little under five thousand dollars. That is my own estimate, reading the freelancer’s time tracking, and it may be inflated; not every hour went into just that. But even cutting it in half, that is 13,000 reais to reconstruct code that was already in the repo.
That is debt that piles up quietly, the kind we treat as a risk spreadsheet, not an engineering complaint.

Reading the whole codebase before touching it is the boring part nobody bills for, and the part that finds the duplication first.
The difference with a team that will maintain what it writes starts before the first line. If I know I will still be in this same repo a year from now, deleting the duplicated function stops being invisible work and becomes self-interest: every copy left standing is a copy I will have to fix again myself. The incentive changes, and the code changes with it. None of this is heroic. It is what happens naturally when the people who write are the people who maintain.
At Revin, the first thing we do when we step into a client is read the whole codebase, in the Diagnostic Sprint, before touching anything. Duplication shows up on that first read: when we audited 31 broken codebases, one of the numbers that kept repeating was not a security hole, it was a copy-pasted function. If you want to see this undone in a real engagement, the cases tell it better than I can.
Every codebase carries the mark of whoever passed through it. One touched by seven serial freelancers looks like exactly that: seven people who did good, self-contained work and left before learning that the system already knew how to send an email. The fault is none of theirs. What was missing was someone who stayed long enough to say "this already exists, do not write it again".
If your product has passed through a lot of hands and you have never sat down to count how many times the same thing got built, here is the invite: it is worth half an hour of someone reading the base with you, before the next fix comes back for the third time. Whenever you like, book a call.
6 read minutes
Article content: