Red flags to watch for when hiring a development agency

Quick answer: the agencies that disappoint share the same patterns — vague scoping, no named technical lead, locked-down code repositories, no documented handover, “we’ll figure it out as we go”, and prices that can’t be explained. The signals are visible early if you know where to look.

Most software projects don’t fail dramatically. They fail by attrition — missed deadlines, scope confusion, mounting change requests, a final product that does most of the brief but feels brittle, and a working relationship that’s deteriorated to email-only by month four.

We’ve been on the building side of those projects for over twenty years and on the cleanup side of plenty more. The patterns repeat. Here’s what to watch for before signing.

1. They can’t name your technical lead

If the agency can’t name — in writing, before contracts — the senior engineer who will architect and own your project, you’re likely buying access to a junior team that will figure it out as they go.

What good looks like: a named technical lead, a short bio, the option to talk to that person before signing, and a clear escalation path if they leave the project.

What a red flag looks like: “our team will assign the right resources”, biographies you can’t verify, “the dev team” as a generic noun.

2. The proposal is identical to the brief

A serious technical proposal pushes back on at least one thing in the brief — a feature that’s expensive for the value it adds, an assumption that’s wrong, a constraint that wasn’t obvious to you. If a proposal echoes your brief perfectly with prices attached, the agency hasn’t thought about it. They’re betting they can sort it out later.

What good looks like: a proposal that includes “we’d challenge X” or “Y is more expensive than it looks — here’s why”, ideally before you’ve paid them anything.

3. Fixed-price for an undefined scope

Fixed-price has its place — tightly-scoped, well-understood projects with clear acceptance criteria. Where it goes wrong is when an agency offers a fixed price for a project the brief doesn’t fully define. The price is a fiction; the change-request invoices that follow aren’t.

What good looks like: either a fixed price for a deliberately-narrowed first phase (with a clear next-phase quote), or time-and-materials with a documented estimate range and weekly burn-rate transparency.

4. They host the code on accounts you don’t own

This pattern is common enough that it has a name in industry literature — vendor lock-in via infrastructure ownership — and it’s usually unintentional, not malicious. Doesn’t make it less expensive to undo.

This one’s subtle and shows up at the worst possible moment.

The pattern: the agency builds your application, deploys it to their AWS / Vercel / GitHub / domain registrar account, and treats access as part of the ongoing relationship. When you eventually want to leave, the migration is a project of its own — one you’re paying the agency to undertake.

What good looks like: from day one, code lives in a repository you own, infrastructure runs on accounts you control (the agency may have user-level access), domains are registered to you, and the credentials list is documented somewhere accessible to you.

This is also the place where reading the contract carefully matters — specifically the parts about where the IP sits and what licence you receive. It’s appropriate for a studio to retain IP in code unless explicitly assigned, but it’s never appropriate for the studio to control your infrastructure in a way that makes leaving hard. Those are different things.

5. No discovery phase — or a discovery phase you can’t see the output of

Discovery is the project’s most leveraged hours. Skipped, you build the wrong thing fast. Done badly, you spend weeks producing slide decks that don’t change the build.

What good looks like: a discovery phase that produces a documented brief, a technical architecture decision record, a list of risks and assumptions, and a phased plan with deliberately-narrowed scope for phase one. You should be able to read the output, disagree with parts of it, and make decisions from it.

What a red flag looks like: “we’ll do discovery as part of the build”, or a discovery phase whose output is a slide deck rather than a working document.

6. Vague answers about how change requests work

Every project has change requests. The question is whether the agency has a clear, repeatable process for handling them, or whether each one becomes a negotiation.

What good looks like: “changes within the original scope are absorbed; changes that expand scope are quoted before work begins; we won’t do work outside the original scope without a change order signed by both parties.”

What a red flag looks like: “we’re flexible”, or invoices arriving for work you didn’t know was being billed.

7. They can’t show you working code from past projects

A polished portfolio site is the easy part. The harder question is: can the agency walk you through the code from a past project they’re proud of and explain the decisions in it?

You don’t need to be technical for this. The signal isn’t whether you understand the code — it’s whether the developer talking through it can explain why things are structured the way they are, where the trade-offs were, and what they’d do differently. If the answer is variations of “the framework decides” or “that’s just how it’s done”, the engineering depth probably isn’t there.

8. They sell you the platform they make commission on

Some agencies are genuinely platform-agnostic and recommend WordPress for the projects where it fits, Astro for marketing sites, Shopify for ecommerce, GoHighLevel for service businesses, and custom code for the cases that warrant it.

Other agencies have a financial incentive in one direction — partner commissions, recurring licence kickbacks, or a team that only knows one platform. That’s not automatically disqualifying, but it’s a question worth asking directly: “In what situations do you not recommend this platform?” If the answer is none, the recommendation isn’t neutral.

9. No documented testing approach

The question to ask: “how do you test this project before it goes live, and how do you catch regressions later?”

The signal is in the specificity of the answer. Vague answers (“our team thoroughly tests everything”) usually mean ad-hoc click-testing. Specific answers describe a mix of automated tests at appropriate levels (unit / integration / end-to-end), a staging environment that mirrors production, and a process for running tests on every change.

Not every project needs a full test pyramid. But the agency should be able to articulate what they test, why, and what they consciously don’t test — not stare at you blankly.

10. Slow or absent communication during sales

If communication is slow before you’ve paid them, it won’t get faster after. Every project has rhythm: weekly check-ins, demos against milestones, written summaries of decisions. The pre-sales pace is a fair signal of the project pace.

What good looks like: responses within a business day, written follow-ups after calls, calendar holds for next steps before you ask.

11. They won’t put hosting, support, and ongoing fees in writing

Most projects need somewhere to run after launch. The honest agencies tell you up front: hosting is $X/month, ongoing support is sold in blocks of Y hours at $Z/hour, here’s how you reach us if something breaks at 2am, here’s how we charge for that.

The agencies to avoid are vague about ongoing costs until after launch — at which point the recurring fees are higher than expected and migration to anyone else is a project of its own.

12. Pricing that can’t be explained

A reasonable agency can answer “why does this cost what you’ve quoted?” with a breakdown: discovery, design, build phases by feature area, testing, deployment, training. The numbers won’t be exact — they’re estimates — but they’ll be coherent and you’ll see where the time is going.

If pricing is a single bottom-line number with no underlying structure, you’re not buying engineering. You’re buying a wager.

What to ask before you sign

A short list of questions that surfaces most of the above:

1. Who will be the technical lead on our project? Can we speak to them?
2. What’s the one thing you’d push back on in our brief?
3. Where will our code and infrastructure live, and on whose accounts?
4. What does your discovery phase produce? Can we see an example?
5. How do you handle change requests within and outside the original scope?
6. Walk us through the code from a past project — explain a decision you’re proud of and one you’d do differently.
7. In what situations do you not recommend this platform?
8. How do you test the project, and how do you catch regressions after launch?
9. What does ongoing hosting, support, and maintenance cost?
10. How is your pricing built up?

The honest agencies will be visibly relieved you asked. The agencies to avoid will deflect.

Common questions

How do I know if a development agency is any good? Ask to meet the technical lead, ask them to walk you through code from a past project, ask what they’d push back on in your brief, and ask where your code and infrastructure will live. Genuine agencies handle these questions easily; the rest deflect.

What questions should I ask a web development agency? The ten questions above are a strong baseline. The most diagnostic single question is “in what situations do you not recommend this platform?” — it instantly separates platform-agnostic agencies from agencies selling what they’re paid to sell.

Should I use a fixed-price or time-and-materials contract? Fixed-price suits tightly-scoped, well-understood projects with clear acceptance criteria. Time-and-materials suits projects where the scope is genuinely uncertain. The wrong-fit failure mode is a fixed-price contract on a vague scope — you’ll pay for it via change requests, slipped deadlines, or both.

Why do so many agency projects fail? Most don’t fail dramatically — they erode. Discovery is skipped, scope is unclear, the technical lead changes mid-project, change requests pile up, the post-launch handover is incomplete, and the relationship deteriorates. The patterns are consistent and visible early if you know to look.

What should be in a good development proposal? A clear statement of what’s being built, who’s building it (with named technical lead), how long it’ll take with milestones, what it’ll cost with a structured breakdown, what the agency is pushing back on in the brief, where code and infrastructure will live, and what the post-launch arrangement looks like.

Should the agency or the client own the code? Code in software engagements is typically licenced to the client for the agreed use, with IP retained by the studio unless explicitly assigned in writing. Crucially though, the client should always own the infrastructure (hosting accounts, repositories, domains) so they can move providers without rebuilding from scratch. We cover the IP position in our Terms of Engagement.

If you’re evaluating us, start a project and ask anything from this list. We’d genuinely rather you ask hard questions up front than discover answers you don’t like later.