Vetting a Dev Agency Before You Sign

The short answer: Evaluate a software development agency by auditing their past work at the code level, talking directly to former clients (not just references they hand you), testing how they handle ambiguity in a scoping call, and reviewing their contract for who owns the IP. Price is the last thing to compare, not the first.

Hiring the wrong development agency is one of the more expensive mistakes a founder can make. Not because the retainer is high, though it often is, but because of what gets built wrong in the meantime. Bad architecture is cheaper to fix at month two than at month fourteen. Features built on a shaky foundation have a way of multiplying the cost of everything that comes after them.

The problem is that most agency evaluation processes are shallow. Founders look at portfolios, sit through a sales call, maybe ask for references, and sign. The agency is incentivized to make that process feel thorough without actually being thorough. A polished case study and a responsive sales rep do not tell you whether the team can handle a pivot at month four or communicate clearly when something breaks on a Friday afternoon.

This guide is for founders and ops leaders who want to do this properly. Some of these steps take effort. That effort is worth it.

Start With the Work, Not the Website

Every agency has a website full of logos and case studies. Most of those case studies were written by a marketing team and approved by legal. They are designed to impress, not inform.

The more useful question is: can you see the actual code?

For agencies that work in open-source adjacent spaces, or for projects where the client will allow it, ask to review a GitHub repository or a staging environment. You are not auditing every line. You are looking for signals: Is the code organized? Are there comments or documentation? Does the commit history tell a coherent story of development, or does it look like a series of panicked pushes before launch dates?

If a code review is not possible, ask to speak with the developers who would actually work on your project. Not the account manager. Not the CTO who will never touch your codebase. The people who will write your software. Ask them how they handle technical debt. Ask them what they do when a sprint estimate turns out to be wrong. Their answers will tell you more than any portfolio.

Reference Calls Done Right

Agencies give you references. Every agency gives you references. They are not going to hand you the number of a client who had a bad experience.

Here is how to get more useful information. Ask the agency for a list of their last six clients, not their best ones. Then find those companies on LinkedIn. Reach out to the product manager or CTO directly, outside the agency's referral chain. Most people will give you fifteen minutes if you ask honestly.

When you get on that call, ask specific questions. Not "how was your experience?" but: Did the final timeline match the original estimate? What happened when there was a disagreement about scope? Would you hire them again, and if not, what specifically stopped you?

That last question catches people. It is harder to dodge than a general satisfaction rating.

Also pay attention to recency. An agency that did great work in 2022 with a different team under different leadership may not be the same agency you are evaluating in 2026. Team turnover in dev shops is high. Ask who specifically will be on your account and whether any of the referenced projects were built by those same people.

The Scoping Call Is an Audition

Most founders treat the initial scoping or discovery call as a formality. It is not. It is the single best opportunity to observe how the agency thinks.

Come with a problem that is genuinely ambiguous. Do not give them a fully specced feature list. Tell them the business outcome you need, then watch what they do with it. Do they immediately jump to a solution? That is a yellow flag. Good technical partners ask clarifying questions before proposing anything. They want to understand the user, the constraints, the existing system before they touch a keyboard.

Ask them about a time a project went sideways and how they handled it. Specifically, how did they communicate with the client during that period? Agencies that have done this well have clear stories. Agencies that have not either deflect the question or give you a vague answer about "transparent communication" without any actual example.

Also notice whether they push back on anything you say. An agency that agrees with everything you propose is not a partner. It is a vendor. Partners tell you when your assumptions are wrong. If you are evaluating multiple options, comparing agency vs. freelance approaches can help clarify which model fits your project's needs at this stage.

Contract Terms That Actually Matter

There are three things in a development agency contract that founders consistently underweight.

The first is IP ownership. Some contracts, particularly from agencies working across multiple clients in a vertical, include clauses that are murky about who owns the code once it is delivered. You want a contract that states clearly that all work product, including any custom code written for your project, becomes your property upon final payment. Read this section carefully. Have a lawyer read it.

The second is the change order process. Scope changes are inevitable. The question is what happens when they occur. Some agencies use change orders to dramatically expand a project budget in ways that were not visible at signing. Others have a fair process. The contract should describe, specifically, how scope changes are estimated, approved, and priced.

The third is termination rights. If the relationship is not working, how do you exit? Some contracts lock you into long notice periods or require you to pay for work in flight even if it is not deliverable. Understand this before you sign, not after the relationship has broken down.

Team Continuity and the Subcontractor Question

One of the more common disappointments founders experience with agencies is the bait-and-switch on talent. You meet a senior engineer in the sales process. The work is assigned to a junior team, sometimes offshore, sometimes through a subcontractor the agency did not mention.

Ask directly: will any of this work be subcontracted? If yes, to whom, and what is the oversight process? Subcontracting is not inherently bad. Many agencies have strong networks and use specialist contractors well. But it should be disclosed upfront, and you should understand who is responsible for quality review.

Also ask what happens if a key developer on your project leaves during the engagement. Some agencies have zero bench depth. If their lead engineer on your account goes to another opportunity, your project stalls for weeks. Others have structured handoff processes. The answer to this question tells you a lot about how mature their operations actually are.

Pricing Models and What They Signal

Fixed-price contracts feel safe. They are not, at least not for complex software projects. When an agency offers a fixed price for something with significant unknowns, one of two things is usually true. Either they have padded the estimate considerably to protect themselves from the unknowns, or they have underestimated and will cut corners or fight you on scope changes to protect their margin.

Time-and-materials or sprint-based billing is more honest for product development work. It puts more budget management responsibility on you, but it also means the agency is not hiding risk inside a lump sum number. Understanding the real cost difference between agency and in-house development can help you make a more informed decision about what pricing model actually makes sense for your stage and runway.

The question to ask is not "what does this cost?" but "how are you accounting for uncertainty in this estimate?" A good agency will walk you through their assumptions, explain where the ranges are, and tell you what would cause costs to go higher. An agency that gives you a clean number with confidence for a complex, ambiguous project is telling you something important about how they approach hard problems.

Red Flags That Are Easy to Miss

Slow response times during the sales process almost always predict slow response times during the project. If it takes four days to get a follow-up email when they are trying to win your business, imagine what communication looks like at month six when you are not the newest contract on their roster.

Agencies that cannot point to a single project that failed or went over budget should give you pause. Every agency that has been around for more than two years has at least one. If they claim otherwise, they are either not being honest or they have not done enough work to have a real track record.

Finally, watch for agencies that position themselves as full-service everything. The best dev shops have a clear specialization. They are great at fintech infrastructure, or consumer mobile apps, or B2B SaaS platforms. They know their lane. Generalists can work, but the best results almost always come from teams that have built something similar to what you are building before.