Skip to content
[ 05 ]Journal

How to Choose a Software Development Agency. Twelve Questions to Ask Before You Sign.

Only about 31 percent of IT projects land on time, on budget and in scope, and the buying process is most of the reason. Twelve questions to ask any software development agency before you sign, from who will do the work to what happens when it goes wrong.

How to Choose a Software Development Agency. Twelve Questions to Ask Before You Sign.
Listen to this · AI voice7 min

How to Choose a Software Development Agency. Twelve Questions to Ask Before You Sign.

Most of the projects that come to us as rescues have the same first chapter. A founder or an operations lead picked a development shop. The shop was pleasant, the proposal was polished, the price was reasonable. Nine months later there is a demo that works on one laptop, an invoice history that does not match the feature list, and nobody left who can explain the code.

The industry's own numbers say this is not bad luck. The Standish Group's CHAOS data for 2020 to 2024, summarised in a January 2026 paper in the PM World Journal, puts the share of IT projects delivered on time, on budget and with the agreed scope at about 31 percent. Roughly 50 percent are "challenged", meaning late, over budget or cut down, and about 19 percent are cancelled outright. Those figures have barely moved in a decade, through the whole rise of agile.

The shops are not all bad. The buying process is. Here are the twelve questions we would ask any agency, including us, before signing.

1. Who, by name, will do the work?

Agencies sell you the people in the pitch and staff you with the people on the bench. Ask for the names and the roles of the engineers and the designer who will touch your product, and ask whether they will be on it full time. If the answer is "we'll assign a team after kickoff", the price you were quoted was for a team that does not exist yet.

2. Can I see a product you shipped, and talk to the client?

Not a case study page. A live URL, a product you can sign up for, and a founder who will take your call. Ask that founder two things: did it ship on the date, and would you hire them again. A shop with a real track record will have three of these ready. A shop that offers "ongoing engagements" as references is telling you something.

3. What is your discovery process, and what does it produce?

The Standish data lists unclear requirements and scope creep among the top causes of failure, and both are decided before the first line of code. A serious shop will insist on a short, paid discovery phase that ends in a written document: what is being built, for whom, what is out of scope, and what it will cost. If the agency is willing to quote a fixed price from a two-paragraph email, they are either guessing or planning to make it up in change orders.

4. Where does the code live, and who owns it from day one?

The repository should be in your account, under your organisation, from the first commit. The agency gets access; you hold the keys. Work product should be assigned to you in the contract, not "upon final payment". We have taken over projects where the client discovered, at the end, that the code was in the vendor's account and the vendor was no longer answering.

5. How will I see progress?

The right answer is working software, every week, on a URL you can click through. Not a status report, not a Jira board, not a slide. If a shop cannot demo something in the first two weeks, the project is already in the half that runs late.

6. How do you price, and what happens when scope changes?

There are three honest models, and we have written about them in detail: fixed price, time and materials, or a monthly retainer. Each has a failure mode. What matters here is whether the agency can explain theirs plainly and tell you how a change request is priced before one happens. Beware the fixed price with no specification attached and the hourly rate with no cap.

7. What is in your stack, and why?

You are not auditing their technology. You are listening for a reason. A good shop picks tools for your problem and can say in a sentence why Postgres over the alternative, why this hosting, why this framework. A shop that builds everything in one exotic stack is optimising for itself. A shop that cannot explain any of it is not doing the choosing.

8. What does handover look like?

Ask to see the documentation from a past project. Ask whether there are tests, a deployment pipeline and a runbook. Ask how long it would take another engineer to make a change without the agency's help. Every project ends, and the only question is whether you will own something or inherit something.

9. How do you work with AI tools, and how do you review the output?

In 2026 every shop uses AI coding tools, and the good ones are faster for it. The question is what sits between the model and your production system. You want to hear about code review, tests and a human who is accountable for every merge. A shop that cannot describe its review process is shipping whatever came out.

10. Have you taken over someone else's project?

Rescue work teaches a team what failure looks like from the inside: the undocumented deploy, the missing tests, the demo that does not survive real data. Agencies that have done it build differently, because they have seen the consequences. It is also the surest sign that other clients trusted them with something that was already going wrong.

11. What will you tell me I should not build?

A vendor paid by the hour has no incentive to shrink the scope. A good one does it anyway. In the first conversation, listen for the moment they push back on a feature, suggest buying rather than building, or ask what the first customer actually needs. If it never comes, every idea you have will be built, at your expense, in the order you mention them.

12. What happens if it goes wrong?

Ask how they handled their worst project. Everyone has one. The honest answer includes what they got wrong and what changed afterwards. The dishonest answer is that there has never been one.

What we would weigh most

If you have time for only three of these, make it the people (question one), the shipped products (question two) and the discovery process (question three). The first tells you who you are actually hiring, the second whether they finish, and the third whether anyone will write down what finished means.

The price matters less than you think. Clutch's own data puts most listed shops at $25 to $49 an hour and US shops at $50 to $99, and the average project on the platform at about $132,000 over about 13 months. Nobody sets out to spend thirteen months. Projects get there one unreviewed week at a time, and the cheapest hourly rate is often the most expensive way to arrive.

Where we fit, plainly

AW3 is a venture studio, not a traditional agency. We build our own products, we hold equity in several of the companies we have helped build, and we take on custom software development for startups and established businesses with the same team. We will answer all twelve of these questions on the first call, and the answer to number eleven is usually the one founders remember.

Sources