8 Red Flags You Hired the Wrong Dev Shop

Dev-shop disasters usually start quietly: a Friday update that says “making progress” three weeks in a row while your launch slips.

You hired a team and wrote them a check. Weeks pass, maybe months, and the updates sound fine. Then one day you realize you’ve spent $40K and you can’t demo a single working feature to your investors. If you’re looking for confirmation that something’s wrong with your dev shop, this is it.

The Standish Group’s CHAOS research has tracked software project outcomes for decades: roughly 19% of projects fail outright, and another 47% come in late, over budget, or missing features. That’s two-thirds.

We’ve been cleaning up after agencies since 2008. Eight warning signs surface again and again - if you recognize three or more, you’ve got a problem, and five means an emergency.

1. No Git Access for You #

Git is the system developers use to store and track every code change. Think of it like Google Docs version history, but for software. You should have read access to it, always.

“But I can’t read code,” you say. Doesn’t matter - your next hire can, and so can a technical advisor or fractional CTO. You own this code because you paid for it. If they won’t let you see it, ask yourself why. What are they protecting? And from whom? (What a transparent remote team looks like is the baseline to compare against.)

The pattern founders describe on r/startups: they ask for repo access, hear “we’ll transfer everything at the end” - and the end never comes. Your code should live in a GitHub organization you own from day one, not theirs.

2. “We’ll Show You When It’s Done” #

This is the big one. A healthy team shows you working software every one to two weeks - not a slide deck or a Figma mockup, but something you can click and watch things happen.

When your agency only shows you the finished product, you’ve lost the chance to catch misunderstandings - a signup flow built for the wrong user, a price hardcoded in the wrong currency - while they are still cheap to fix.

Good teams send plain-English async standups daily and a one-page summary every Friday covering what shipped, what’s blocked, and what’s next.

3. Estimates That Keep Growing #

The project was $30K, then $45K, and now they’re hinting at $60K while the feature list got shorter.

Two explanations, and neither is good: they either quoted too low to win the deal, or they’re drowning in technical debt - rework caused by code that was badly written the first time. LitsLink reports that developers spend 42% of their time on technical debt and maintenance. Nearly half their hours go to fixing old mistakes, not building new features.

Budget creep usually means the team didn’t plan or test properly. And now they don’t want to tell you the real number, so they drip it out $15K at a time.

4. No Automated Tests #

If your agency skips one thing, this is the one that kills you.

Automated tests are tiny programs that check whether your software works correctly. Every time a developer changes something, these tests run automatically and report back: “yes, everything still works” or “no, you just broke checkout.” Without them, nobody knows what’s broken until a real user finds it - maybe your biggest customer, maybe on launch day.

We hold our own projects to 70%+ test coverage. Whatever your agency’s bar is, ask for the number. If they hedge or change the subject, the answer is close to zero.

We screwed this up early in our own history - our team took over a project once and assumed the existing tests were solid. They weren’t - they were decorative, passing every time because they didn’t actually test anything. Now we write tests before code, every time. It’s slower on day one but dramatically faster by month two.

Why This Is Worse in 2026 #

The rise of “vibe coding” - agencies using AI to generate 90%+ of the codebase - has made this red flag catastrophic. AI-generated code looks clean, with good variable names and consistent formatting that reads like a textbook.

But the developers who generated it wrote no tests, skipped error handling, and left the edge cases unchecked. Qodo’s 2025 report found AI-generated code produces 1.7x more issues than human-written code. And when Veracode tested over 100 LLMs, their researchers discovered that 45% of the generated code contained exploitable security flaws.

The vibe coding shops skip tests entirely because the AI output “looks like it works.” It does - until real users show up and everything breaks at once, leaving you paying emergency rates to fix code that should never have shipped.

If your agency can’t tell you their test coverage number, they might not have tests at all. And if they don’t have tests but they’re shipping fast, they’re probably vibe coding - and you should be looking for an exit.

5. Can’t Explain Technical Decisions in Plain English #

A founder forwarded us a status email last quarter that said “we’re refactoring the microservices architecture to improve the API gateway throughput.” She had no idea what to ask back.

That sentence usually means one of two things: the developer doesn’t understand it themselves, or they’re hiding behind jargon so you stop asking questions. Either way, the founder ends up paying for words.

Every technical decision costs you money or saves it. Ask which. “We’re splitting the code into smaller pieces so that when one part breaks, the rest keeps working.” That’s the same thing, in English. A good team explains decisions plainly because they want you to make informed choices. A bad team explains nothing because they don’t want you involved.

6. Single Point of Failure #

Ask: “If your lead developer quit tomorrow, what happens?”

If the answer involves panic, you have a bus factor of one. (Industry term for “what happens if someone gets hit by a bus.”) One person holds the passwords, understands the architecture, and knows why that weird workaround exists - everyone else guesses.

Good teams practice structured onboarding and pair programming so knowledge spreads across at least two or three people. Their developers document decisions where you can find them, and someone who didn’t write the code reviews every change. If one person leaves, the project slows down but it doesn’t stop.

The bus-factor bill shows up in the stories founders tell on Indie Hackers: the agency’s senior dev leaves, the remaining two can’t explain half the codebase, and three salaries keep buying one person’s output. That’s the cost of concentrating all knowledge in a single head.

7. They Blame the Previous Team and Push for a Rewrite #

“The last developer wrote terrible code. We need to start over.”

Sometimes that’s true. But we’ve watched founders pay for two full rewrites by two different agencies, each one trashing the work that came before. The codebase didn’t improve either time because neither team enforced testing or code review - they just rewrote the same problems in a different style.

A good team opens an inherited codebase and says:

“Here’s what’s working, here’s what needs fixing, and here’s the cost of each option.”

They give you a repair estimate alongside a rewrite estimate and explain the trade-offs honestly. Skipping the diagnosis is the tell: a rewrite is easier to sell, and it resets the clock on accountability - if everything is new code, nobody can blame them for the old bugs, at least not for six months.

When your agency’s first move is “throw it all away and let us rebuild,” ask them to show you the specific technical problems that make a rescue impossible. If they can’t name them, they’re selling you a fresh start they haven’t earned.

8. Invoice Surprises #

The invoice arrives $4K over the monthly retainer with a one-line explanation about “infrastructure issues.” Nobody flagged anything in the weekly update. Nobody asked you to approve overage spend before they incurred it.

Good teams track hours per task and share them weekly so you know exactly where money goes, and you see overages coming before they arrive. Deloitte’s 2024 Global Outsourcing Survey found that 70% of executives had pulled outsourced work back in-house - with budget unpredictability among the cited drivers.

The bigger problem is what the invoice tells you about the relationship: someone on their team made a decision to keep you in the dark until the bill landed.

We’ve cleaned up after dozens of failed dev-shop engagements, and the recent ones all look the same: test coverage in the single digits, no code-ownership clause in the contract, and six figures already spent by the time the founder calls.

If three or more of these sound familiar, we do a free 45-minute code audit. One senior developer looks at your codebase and writes a one-page assessment: test coverage, security risks, architecture quality. No contract, and no follow-up calls unless you ask. Get an honest audit.

Green Flags Worth Checking #

Not every agency is bad. The good ones:

• give you repo access from day one
• show working software every week or two
• write test-first by default and document decisions where you can find them
• send a written Friday update: shipped, blocked, next
• estimate in ranges with a named risk list: “8-12 weeks, with these three things that could push it to 14”
• keep at least two people fluent in every part of the system
• flag overages before they happen, so invoices match expectations

The Scorecard #

Count your red flags. Be honest.

If your scorecard landed in the orange or red zone, the next call isn’t “fire or stay” - it’s “salvage or rebuild.” The free Salvage vs Rebuild: 6-Question Decision Tree lesson walks that decision.

What to Do If You See 3+ Red Flags #

Don’t panic, and don’t send an angry email at midnight. Here’s the sequence.

Tonight - not tomorrow - verify you have access to your code repository, hosting accounts, domain registrar, and all third-party services. If anything is under their email instead of yours, start transferring it now.

This week, get a second opinion. Hire a freelance senior developer or fractional CTO for 4 hours and have them look at the code. They’ll tell you - in plain English - what shape it’s in. This costs $500-$2,000 and might be the most important money you spend this year.

Within 30 days, make a decision. Either set measurable improvement targets (repo access, weekly reports, test coverage number) with a hard deadline, or begin the exit. Our step-by-step exit guide covers the mechanics, and if you need someone to manage the transition, the 5 warning signs you need technical leadership will help you decide.

Before you hire the next team, don’t fall into the outsourcing trap twice. Ask for a sample weekly report, a real test coverage number, and a contract with milestone-based code ownership - in our rescues, these are the three requests bad agencies refuse.