What code review tools and methods should we use for agency-delivered code?

When setting up static analyzers, focus on security-centric SAST rules, not just linting and styling. SQL injection paths, insecure direct object references (IDOR), and missing input sanitization get flagged by good rulesets very easily. Also check test coverage; if the agency skipped unit tests, refactoring that codebase is going to be miserable.

We took over a mobile backend last year under similar circumstances for around $40,000. Automated scanners gave it a clean bill of health because the syntax was pristine. Two weeks post-launch, the database locked up completely: turns out the agency hadn't added a single foreign key or index across the relational DB. No automated linter will ever catch that.

During handoff, we paid $2,500 to an independent principal architect for a 15-hour deep dive. They uncovered 4 major scalability bottlenecks and 8 critical authorization loopholes in the agency's delivered code. It was easily the highest-ROI money we spent on that project.

Don't be fooled by automated tool reports on agency work. Sometimes agencies break functions into tiny pieces just to silence static analysis warnings and write so-called clean code, but the business logic underneath is pure spaghetti. Tools don't verify that code works correctly, they just tell you it follows syntax rules.

The first thing you can do first thing tomorrow: check the repository's version history (git log). Did the agency panic-push everything in the last 3 days, or did they work steadily over 4 months with regular commits and descriptive messages? Version control discipline tells you almost everything about the internal quality of the code.

Checklist for agency handoffs: 1) Are third-party API keys left hardcoded in the source? 2) Do the licenses for open-source libraries permit your commercial use? 3) Do deployment and local setup instructions work end-to-end from a single document?

def check if they wrote tests imo. tbh agencies usually skip unit tests claiming they ran out of time then later you change one line of code and the whole architecture comes crahing down.

cut your new senior hire some slack. like inheriting someone else's codebase is the most frustrating job on the planet for developers. automated tools at least keep discussions from getting personal and ground them in objective metrics.

Noted, thanks.

I'm curious too.

Following.

Great work. The answer varies greatly by industry; there is no one-size-fits-all rule.

Just leaving this note, it might be useful.

the cheap-looking path usually ends up costing more later. when making decisions write down the worst-case scenario too not just the best.

when you try to change everything at once, noting settles... if you post the result here it will help others too.

My perspective changed after experiencing that. Code without setup documentation isn't yours, even if you have it.

If you post the result here, it will help others too.

I agree.

We've heard this a lot, but it never happened like that for us. Payment schedules should be tied to project phases, not calendar dates.

If I were you, I'd go this route.

I've been down this road, let me tell you. Weekly written progress reports are much more useful than asking for dates.

Same here. Everyone rushing into code review tools gets stuck at the same point.

Start with a small trial; don't commit to everything at once. If I were you, I'd go this route.