How to vet a software agency before signing

The agency with the best portfolio in your final three is not necessarily the one that will deliver your project on time and on budget. The gap between what you see in a demo and what you get six months later has almost nothing to do with technical ability. If you’re evaluating custom software development partners, this distinction matters more than you might think. It comes down to how they handle ambiguity, how they communicate when problems surface, and whether they can translate what you need into working software without requiring you to specify every detail.

Most vetting advice focuses on credentials and past work. That matters, but it misses the signals that predict success more reliably. A skilled team that disappears when requirements get complex or scope disputes surface will cost you more than a less experienced team that communicates constantly and owns the outcome.

What actually predicts whether the project will succeed

The single best predictor is how an agency handles the discovery phase. If they can produce a detailed proposal after one or two conversations without asking clarifying questions, they are guessing. If they push to start coding immediately, they have not understood the problem yet.

A manufacturing software company we worked with had tried twice to automate their quality control workflow. Both previous agencies delivered systems that technically worked but did not match how inspections actually happened on the floor. The inspection steps were in the wrong order. The data model assumed inspections happened linearly when most required iterative checks. The interface required five clicks for what used to be a single clipboard entry.

The technical work was fine. The problem was that both agencies started building before they understood the workflow. When the client pointed out the mismatches, both agencies treated it as scope creep rather than incomplete discovery.

In the initial conversations we run, the first two to three hours are spent mapping the current process in enough detail that we can identify where automation will create friction rather than remove it. The code comes after. If an agency is not asking those questions before estimating, they are estimating based on what they assume the problem is, not what it actually is.

Red flags that show up before you sign anything

Vague scope language in the proposal is the most common warning sign. If the proposal says “build a dashboard” without listing what data sources feed it, what views different roles need, or how updates get prioritized, you are looking at a scope dispute waiting to happen.

The second red flag is when an agency cannot explain their communication structure. If they cannot tell you who your day-to-day contact will be, how often you will have working sessions, and how decisions get documented, communication will break down under pressure. Most project failures we see are communication failures, not technical failures.

The third is if they resist putting success criteria in writing. A proposal should include specific deliverables and measurable outcomes. “Improved efficiency” is not measurable. “Approval cycle time drops from 11 days to under 2 days” is measurable. If the agency pushes back on defining success clearly, they are keeping flexibility to declare the project done when it is not.

Another signal is how they price the work. Fixed-price contracts with no provision for scope refinement suggest the agency is either padding the estimate heavily or plans to cut corners when reality does not match the initial plan. Hourly billing with no cap creates the opposite problem. The right structure usually involves phases with fixed costs per phase and clear deliverables that trigger the next phase.

Questions that reveal how they handle problems

Ask what happens when a requirement turns out to be more complex than estimated. The answer tells you whether they view the project as collaborative problem-solving or as a contract to be enforced. An agency that immediately talks about change orders is signaling they will treat every complexity as scope creep. An agency that talks about how they handle technical surprises within the agreed scope is signaling they take ownership of delivering the outcome, not just the hours.

Ask for an example of a project that went wrong and how they handled it. If they claim every project goes smoothly, they are either lying or have not done enough projects to encounter real complexity yet. The best answer includes specifics about what failed, what they did to recover, and what they changed in their process afterward.

Ask how they handle disagreements about whether something is in scope. This question surfaces whether they have a documented scope management process or whether disputes get resolved based on who argues harder. In most engagements we run, scope questions come up at least once per month. The difference between a smooth project and a contentious one is whether there is a clear process for resolving those questions without stopping work.

Ask what their policy is on knowledge transfer and handoff documentation. If the answer is vague or treats documentation as optional, you will be locked into them for maintenance indefinitely. A good agency plans for you to own the system fully, which means detailed architecture documentation, runbooks for common issues, and training for your team.

What the proposal and contract should contain

The proposal should list every major deliverable as a discrete item with a definition of done. Not just “approval workflow system” but “approval workflow system with role-based routing, email notifications, audit log, and admin interface for modifying approval chains.” The more specific the deliverables, the less room for misalignment later.

It should include a communication plan. How often do you meet? Who is responsible for documenting decisions? How do you request changes or clarifications? This seems procedural, but it is the difference between a project where small questions get resolved in hours versus one where they pile up into multi-week delays.

The contract should specify who owns the code and all related intellectual property. Standard practice is that you own everything custom-built for your project. If the agency resists that, they are either planning to reuse your work for other clients or are using a template they do not want to transfer ownership of. Both are problems.

It should include specific response time commitments for bugs and production issues after launch. “We provide support” is not specific enough. “We respond to critical production issues within 4 hours and resolve or provide a workaround within 24 hours” is specific.

The payment structure should be tied to deliverables, not just time. Paying half upfront and half on completion creates the wrong incentives. Paying in milestones tied to working software delivered and accepted keeps both sides aligned. In the projects we structure, payment usually breaks into 25% at kickoff, 50% across two or three interim deliverables, and 25% at final acceptance and handoff.

The cost difference between a bad choice and the right choice

Choosing the wrong agency costs more than the contract value. A retail operations team paid $47,000 for an inventory sync system that never worked reliably. They spent another six months trying to get fixes. Eventually they hired a different agency to rebuild it from scratch for $35,000. Total cost was $82,000 plus 14 months of calendar time to get a working system they could have had in 4 months.

The pattern is consistent across most failed projects. The initial cost looks appealing. The agency delivers something that technically meets the contract but does not solve the actual problem. Fixing it costs more than doing it right the first time, and the calendar delay often costs more than the dollar amount. If that inventory sync was supposed to support a new fulfillment process that got delayed by a year, the opportunity cost was likely in the six figures.

The difference in upfront cost between a cheap agency and a competent one is usually 30% to 50%. The difference in total cost when you account for rework, delays, and lost opportunity is often 200% to 400%. The lower bid is rarely the lower cost.

The other pattern we see is agencies that underbid to win the work, then try to make it up through change orders. Every clarification becomes a scope change. Every bug that should have been caught in QA becomes a new feature request. The final cost ends up higher than the higher bid would have been, and the relationship is adversarial the entire time.

How to make the decision

The best way to evaluate competing proposals is to compare them on specificity, not just on price. Which proposal has the clearest deliverables? Which one acknowledges the complexity you actually have rather than oversimplifying it? Which communication plan makes it easiest for you to stay informed without having to chase updates?

If one proposal is significantly cheaper than the others, the question is what they are not including. Usually it is either discovery time, testing, or post-launch support. Sometimes it is that they estimated assuming everything will go smoothly. In software projects, something never goes smoothly.

The second filter is whether the agency is asking hard questions about your internal process and constraints. If they are not asking who will test the system, who will make decisions when you are unavailable, or how this fits into your existing tools, they have not thought about implementation complexity. Those questions usually surface problems early. Avoiding them just defers the problems until the middle of the project when they are harder to solve.

If your situation involves human-in-the-loop workflows, approval routing, or replacing a process that currently lives across spreadsheets and email, the vetting process should focus heavily on process discovery. Those projects fail most often because the agency starts building before the workflow is fully understood. If you want to compare notes on how the discovery phase should work for your specific situation, let’s discuss building custom software.