Red flags when hiring a development agency

By the time you are interviewing agencies, you have usually decided the project is worth doing. The risk is no longer "should we build this." It is "will this team deliver it or sink it." That is a harder thing to judge from a polished pitch, because the worst engagements rarely look bad on day one. They look confident, fast, and reassuring, right up until the silences start.

The good news is that the failures leave a trail of tells, and most of them show up before you sign anything. You do not need to be technical to spot them; you need to know what behaviour to read. Here are the red flags we would back away from, what each one actually signals, and what a competent partner does instead.

A fixed price before they understand the work

The most seductive red flag is also the most expensive: a confident, fixed quote delivered before anyone has understood what you are building. It feels great. A number, finally, and a precise one. But nobody can price software accurately without first understanding the goals, the data, the edge cases, and the things you have not thought of yet. A precise quote on a vague brief is not confidence. It is a guess wearing a suit.

What usually happens next is one of two things. Either the team padded the number heavily to cover their own uncertainty, and you overpay, or they lowballed to win the work and recover it later through change requests for everything not explicitly written down. A serious team treats discovery as part of the job. They will scope before they price, or quote a small paid audit first, and explain where the real unknowns are. If you are weighing the trade-off itself, our take on fixed-price versus hourly walks through when each one actually protects you.

They ask nothing about your business

Watch what an agency is curious about. A team that opens with their tech stack, their awards, and their process, and never asks why this project matters to your business, is telling you how the engagement will go. They will build what is written down, correctly, and it will miss the point, because nobody on their side ever understood the point.

The best discovery calls feel a little like being interviewed. Who are your users. What happens today without this. What does success look like in a number. What would make this a waste of money. Those questions are not filler; they are how a partner finds the cheaper, smarter solution to the problem behind your feature request. A team incurious about your business will never catch you before you spend money on the wrong thing. It is the same instinct that makes a good discovery and consulting engagement worth more than the hours it costs.

They run down the last developer

It is tempting to trust someone who agrees that your previous team was hopeless. Resist it. Reflexively disparaging the last developer to win your confidence is a tell, not a kindness. Today's hero is tomorrow's villain, and the team trashing your old code to a stranger is showing you exactly how they will talk about you to the next client.

There is also a practical problem behind the bluster. Inherited code usually encodes real, hard-won decisions about your business, and a team that dismisses it sight unseen is a team that would rather rebuild than understand. That is slower, riskier, and more expensive than it sounds. A grounded partner reads the existing system before judging it, which is the whole premise of rescuing a stalled project rather than torching it. Respect for the work that came before is a strong signal of how they will treat yours.

"We'd just rebuild it"

Closely related, and serious enough to earn its own flag: the team that reaches for a full rewrite before they have read a single file. A rebuild is sometimes the right call, but it is never the safe default. It means months with no new features, the constant risk of recreating old bugs, and two systems to maintain while you cross over. A team that proposes it casually, in the first meeting, with no audit behind it, is choosing the option that feels productive to them over the one that is safe for you.

The honest version sounds different. "We would need to understand what you have before we can say whether it is worth keeping." That is not indecision; it is the only responsible answer this early. The rewrite question deserves the same scrutiny as any build-versus-buy decision, and a good partner will show you the reasoning rather than assert the conclusion.

Vague timelines and communication black holes

Two related flags here, because they tend to travel together. The first is a timeline made of vapour: "a few months," "soon," "we move fast," with no milestones you could actually check against. Vague timelines are not optimism. They are the absence of a plan, and they become the "almost done" that stretches across a whole quarter.

The second is how they communicate while you are still a prospect. If replies are slow, questions go half-answered, and you are already chasing for updates before any money has changed hands, that is the best this relationship will ever be. It does not improve after you sign; it gets quietly worse. A dependable team gives you a cadence, names who you will talk to, and ships in small, visible increments rather than a big reveal in three months. You can see how we structure that on our how we work page, and it is the difference between a partner and a black box.

No plan for handover or ownership

The last flag is the one nobody asks about until it is too late. Ask, plainly, what happens at the end. Who owns the code. Where it lives. What you walk away with if the relationship ends. A team that gets cagey here, that keeps the repository on their own accounts, that resists writing anything down, is building your next dependency rather than your asset. The black box is sometimes the business model.

What good looks like is boring and reassuring. The code is yours, in your accounts, from the start. There is enough documentation that another team could pick it up. Handover is treated as a feature, not a threat. A partner confident in their work has no reason to hold yours hostage, which is why a clear ownership story sits right alongside a sane maintenance and support plan in any engagement worth signing.

The takeaway

The pattern under all of these is the same. A safe pair of hands reduces your risk: they scope before they price, ask about your business, respect the work that came before, plan in visible increments, and hand you something you own. A weaker one offloads risk onto you, with premature certainty, incuriosity, and a quiet reluctance to let go. None of it requires you to read code. It requires you to read behaviour, and the behaviour is on display before you sign.

If you would like a second opinion on a team you are considering, or you want to feel the difference for yourself, our guide to choosing a web development agency covers the positive side of the same coin. When you are ready, tell us about your project and watch how many questions we ask before we quote a thing. That is the good kind of lazy: doing the diligence early so you never pay twice for the same software.