Back to BlogBusiness

How to Evaluate a Dev Agency Without Getting Burned

CX

CodeVix Labs

Engineering Team

March 20268 min read

Hiring a development agency is one of the highest-stakes decisions a founder makes. Get it right, and you have a technical partner who accelerates your vision. Get it wrong, and you've lost months of time and tens of thousands of dollars. Here's how to tell the difference before you sign anything.

Red Flags to Watch For

These are the warning signs we've seen correlate most strongly with projects that go off the rails:

  • No public portfolio or case studies — If an agency can't show you what they've built, that's either because they haven't built much or because their clients didn't want to be associated with the work. Neither is a good sign.
  • Vague timelines and “it depends” pricing — Every project has unknowns, but a competent agency should be able to give you a range and explain what drives the variance. “We'll figure it out as we go” means they haven't done enough discovery to understand your project.
  • No process documentation — How do they run sprints? How do they handle scope changes? What does their QA process look like? If they can't articulate this, they're making it up as they go.
  • Pushback on NDA or IP discussions — Legitimate agencies sign NDAs routinely. If there's hesitation around intellectual property ownership, walk away. You're paying for the code — you should own it.
  • They say yes to everything — A good agency pushes back on bad ideas. If they agree with every feature request and every timeline demand, they're either not thinking critically or they plan to under-deliver.

Green Flags That Matter

These are the indicators that an agency takes their craft seriously:

  • Weekly demos of working software — Not slide decks, not wireframes, not “progress updates.” Actual working features you can click through. This is the single best indicator of a healthy project.
  • A clear Statement of Work — Defined scope, milestones, deliverables, acceptance criteria, and payment terms. The SOW should be specific enough that both sides can objectively determine whether a milestone is complete.
  • Test coverage they can show you — Ask to see test coverage reports from a past project. Agencies that write tests ship more reliable software. If they don't test, you're the QA team.
  • Transparent communication patterns — A shared Slack channel, regular standups, a project management board you can access. Silence between demos is a red flag; consistent, proactive updates are a green one.

Questions to Ask Before Signing

These questions reveal more about an agency's capabilities than any sales pitch:

  1. 1

    What's your QA process?

    The answer should involve automated testing, not just "we test manually before each release."

  2. 2

    Can I see test coverage reports from a previous project?

    If they can't produce these, they probably don't write tests consistently.

  3. 3

    What happens when scope changes mid-project?

    Look for a structured change request process, not "we'll handle it."

  4. 4

    Who will actually be working on my project?

    Make sure you meet the developers, not just the sales team. Ask about their experience level.

  5. 5

    Who owns the intellectual property?

    The answer should be "you do" — full IP transfer upon payment. Anything else is a dealbreaker.

  6. 6

    What does your deployment and handoff process look like?

    You need documentation, access credentials, and the ability to maintain the code independently.

Contract Must-Haves

Before you sign anything, make sure the contract includes these non-negotiable elements:

  • IP transfer clause — All code, designs, and deliverables become your property upon payment. No shared ownership, no licensing fees, no strings attached.
  • Defined milestones with acceptance criteria — Each milestone should have a clear definition of done. Payments should be tied to milestone completion, not calendar dates.
  • Post-launch SLA — What happens after launch? Define response times for critical bugs, the support period included in the contract, and the cost of extended support.
  • Source code access throughout — You should have access to the repository from day one, not just at handoff. This protects you if the relationship goes south and ensures transparency.
  • Clear payment terms — Avoid 100% upfront. A typical healthy structure is 20-30% upfront, with the remainder tied to milestone completion. Both sides should have skin in the game.

The Trial Project Approach

Here's the single best piece of advice we can give: start with a small, paid discovery sprint before committing to a full build.

A 1-2 week paid discovery sprint — typically $3,000-$8,000 — tells you everything you need to know about an agency. You'll see how they communicate, how they handle ambiguity, how they document their work, how they manage scope, and what the quality of their output looks like.

A discovery sprint is like a first date — except you both get something useful out of it regardless of whether you continue. You get a validated scope document, technical architecture, and a realistic estimate. The agency gets a clear understanding of your product.

If the discovery sprint goes well, you have high confidence in the full engagement. If it doesn't, you've learned that lesson for the cost of a sprint instead of a full contract. Either way, you win.

BusinessAgencyHiringStartups

Ready to discuss your project?

Book a free 15-minute technical audit with our engineering team.