The agency handed over the code, now they're suggesting a "code audit" — why should we pay for this again?

You got a custom suit tailored, and while handing it over the tailor goes, "Want me to check if the seams will rip for 5 grand in rubles?" An agency model that doesn't trust its own code is quite a creative side hustle, honestly.

A code audit looks at the level of technical debt. Developers sometimes write spaghetti code or skip writing tests to meet deadlines. The system runs for now, but it'll crash on the very first update. An audit is valuable for uncovering these exact risks.

Don't pay the agency. Hook open-source static analysis tools up to your GitHub or GitLab repo. Even automated tools will list duplicate code and basic security vulnerabilities in 10 minutes for free.

We skipped the audit on a project we paid 650,000 RUB for; 6 months later, when we wanted to add new features, another agency said "this code is garbage, we have to rebuild from scratch" and we burned another 500,000 RUB. An independent check is a must.

If you're going to get a code audit, have them check 3 things: 1) Database query optimization, 2) Input parameter sanitation, 3) Code documentation. If these are solid, another developer can easily take over tomorrow.

selling an audit for stuff they wrote themselves is such a hustle lol but anyway just pay an indepenednt third party for a couple hours of consulting to give it a quick once-over that's plenty.

Are acceptance criteria and a warranty period included in your initial contract? If there's a clause for "compliance with clean code and architectural standards," they are legally obligated to deliver on that for free as an acceptance condition anyway.

If I understood correctly, you're saying: Everyone rushing into code audit gets stuck at the same point.

People defend habits, not processes. Resistance comes from there. Hope this helps.

I went through the same thing two years ago. Weekly written progress reports are much more useful than asking for dates.

Start with a small trial; don't commit to everything at once.

The discussion got scattered, let me summarize. Payment schedules should be tied to project phases, not calendar dates.

Proven by experience.

Let's separate the concepts they're getting mixed up. Everyone rushing into code audit gets stuck at the same point.

If acceptance criteria arent written when the work is done is open to debate.

There are three things to check when doing this. Implementing a change request process doesn't slow things down, it speeds them up.

People defend habits, not processes. Resistance comes from there. Of course, it varies if your situation is different.

Let me summarize the topic, since several different answers were given. If you get three different answers on a topic, the question was asked wrong.

Hope this helps.

Correct. Most time waste accumulates in tasks waiting for approval.

Just because everyone does it doesn't mean it's right. Hope this helps.

I've been dealing with this for a long time. Payment schedules should be tied to project phases, not calendar dates.

The cheapest quote is usually the least thought-out one. Hope this helps.

Thanks for writing this, that's the right way. Access credentials should be opened in the company's name, not personal accounts.

Weekly written progress reports are much more useful than asking for dates. If you post the result here, it will help others too.

Let me speak from the other side; I'm on the supplier side. Any unwritten clause becomes a point of disagreement later, as both sides remember it differently.

Hasty decisions become decisions you have to fix six months later.

Thanks that was the answer I was looking for.