5 GitHub Red Flags That Reveal a Dev Agency's Real Quality

You're about to hand millions of dollars worth of development to a stranger. A website says they're great. References say they're great. But before you sign, there's one place where a dev agency can't lie: their GitHub repositories.

A dev agency's public code is their report card. No amount of sales talk can fake a clean commit history, comprehensive tests, or modern architecture. In the next 15 minutes, I'm going to teach you exactly what to look for—and what to run from.

Ghost Repositories: The Project Graveyard

You're scrolling through their GitHub profile. You find a project they built for a Fortune 500 client. You click it. Last commit? October 2019. It's a ghost repo—abandoned, untouched, left to rot.

Why this matters: A ghost repo tells you one of three things. One, they built it and forgot about it (maintenance issue). Two, they built something that broke and never fixed it (quality issue). Three, they did client work, got paid, and completely ghosted the code (accountability issue). None of those are good.

What to look for instead: At least some recent activity. Not every project needs daily commits, but if they're using a codebase in production, there should be commits in the last three months. Security patches, dependency updates, at minimum. Look for repos where the last update was within the past year.

Pro tip: Ask them directly about old projects. "I see this repo from 2019—what happened with that one?" Their answer tells you whether they maintain work or abandon it.

Single-Contributor Repos from a "Team" Agency

The agency website says "team of 15 developers." You look at their showcase projects. Every repo shows one person—call them "john-smith-dev"—committing 100% of the code. No code reviews. No collaboration. Just one person grinding.

Why this matters: This is either deceptive marketing (they're one person pretending to be a team) or it reveals their actual process. Real teams collaborate. Real teams have code reviews, pull requests, and multiple people touching the codebase. If you see one person committing everything, either the "team" doesn't exist, or they're not using any collaborative practices.

Both are problems. If they're solo, they're lying about capacity. If they're a team but work like a solo developer, they have no quality checks, no code review process, and no knowledge sharing. Your project is at risk.

What to look for: Multiple contributors on production-level projects. Pull requests. Code review comments. This shows collaboration, quality gates, and institutional knowledge.

Commit Messages That Look Like Keyboard Smashing

You're looking at the commit history. It reads like this:

Why this matters: Commit messages are the bread crumbs of your codebase. When you're debugging a problem six months later, you'll look at the git history and ask "why was this line changed?" If the message is "asdf," you've got nothing. You're flying blind.

Bad commit messages show three things: one, they don't care about future maintainability (it's all about getting it done today). Two, they don't have code review (if a PR required review, someone would ask for better messages). Three, if you hire them, your code will be equally undocumented.

What to look for: Messages like "Add user authentication flow" or "Fix race condition in order processing." Specific, descriptive. They tell you what changed and why. This shows craftsmanship.

No Tests or CI/CD Pipeline

You look at the project structure. No tests folder. No .github/workflows. No GitHub Actions badge. No mention of continuous integration anywhere. They're just pushing code straight to production with no safety net.

Why this matters: Tests are insurance. They catch bugs before users do. CI/CD is a quality gate—automated checks that prevent broken code from reaching production. If a dev agency isn't writing tests, they're not catching their mistakes until your users find them. That costs you money, credibility, and time.

This is huge. A project without tests isn't maintainable. The first time you need to add a feature or fix a bug, it's terrifying. You change something, and you don't know what else broke. The cost to maintain and improve the code balloons.

What to look for: A /tests or /spec directory. Look for a README that mentions test coverage. Check for a GitHub Actions workflow file (.github/workflows/tests.yml) that runs tests on every push. This shows discipline.

Boilerplate Without Customization

You find a repo. It's a clone of a popular template. The README is the template README. The code looks identical to the official boilerplate. They literally copied and pasted, maybe changed a few variables, and called it a day.

Why this matters: Boilerplates are a starting point, not a finished product. Real developers customize them for the actual project needs. They remove unused code, add production-grade error handling, optimize for their use case. If you see raw boilerplate, you're seeing lazy work.

This also suggests they're building everything from templates—which means they might not actually understand the underlying tech. They're template-shoving without critical thinking about whether it fits your needs.

What to look for: Evidence of customization. Project-specific configuration. Removed boilerplate code that wasn't needed. Custom utilities. This shows they built something, not just copied something.

Your GitHub Audit Checklist

Want to evaluate their entire tech stack?

GitHub code quality is one piece. Check their entire tech stack—frontend frameworks, backend infrastructure, databases, hosting—with our Tech Scanner tool. Get a full picture before you commit.

Related Reading

GitHub doesn't lie. A developer agency's repositories are a transparent window into their actual practices, quality standards, and professionalism. Before you write that check, spend 20 minutes auditing their code. It's the cheapest due diligence you can do.

The five red flags we covered—ghost repos, single contributors, bad commit messages, no tests, and boilerplate code—are disqualifying. Any one of them is a reason to keep looking. If you see all five, move on immediately.