How to Vet a Software Development Agency: 15 Questions to Ask Before You Sign
Vet a software agency before you sign: who does the work, proof you can check, code ownership, delivery, continuity and the contract terms that protect you.
Key Takeaways
- Vetting an agency means checking five things: who will do the work, what they have delivered, who owns what, how delivery is run, and what happens if someone leaves.
- Ask for evidence you can check, not claims: named engineers with public profiles, a past client you can call, a company registry entry, sample documents from a previous project.
- Your contract should give you ownership of the code from day one, keep repositories and hosting in your accounts, and set milestones with written acceptance criteria.
- The cheapest low-risk test is a paid discovery phase: a few weeks of real work that leaves you with a written plan you own, whether or not you continue.
- The strongest red flags are vague answers about who works on your project, code held in the agency's accounts, and a firm price before anyone asked about your data or users.
Vetting a software development agency means verifying, before you sign, that the team can actually deliver your project and that the contract protects you if it can't. Most buyers compare portfolios and prices; the projects that go wrong usually fail on things neither shows: who really writes the code, who owns it, and what happens when something changes. This guide gives you the questions to ask, what a good answer sounds like and how to check it.
The five things to verify
| Area | What you need to know | How to check it |
|---|---|---|
| People | Who will do the work, how senior they are, whether they stay | Named engineers, public profiles, a call with the people themselves |
| Track record | Whether they have delivered something of similar complexity | Case studies with specifics, a reference call with a past client |
| Ownership | Who owns the code, data and accounts | The contract's IP clause, where repositories and hosting live |
| Delivery | How scope, progress, quality and changes are managed | Sample plans, acceptance criteria, how change requests are priced |
| Continuity | What happens if a key person leaves or the agency disappears | Documentation practice, two people per project, code in your accounts |
15 questions to ask, and what a good answer sounds like
People
- "Who exactly will work on our project, and can we speak to them?" A good answer names people and lets you talk to the engineers, not just the sales lead. Be wary of "we'll assign the best available team".
- "Are they employees, partners or freelancers, and is any work subcontracted?" Any model can work; what matters is a straight answer and a written agreement covering confidentiality and IP with everyone who touches your code.
- "Who makes the architecture decisions, and who is accountable for delivery?" You want one named person accountable for the outcome.
Track record
- "Can you show a project with similar complexity?" Look for comparable problems (integrations, data, regulated steps), not similar visuals.
- "Can we speak to a past client?" A confident agency arranges a reference call after a first meeting. Ask the reference what went wrong and how it was handled.
- "Can we see a sample deliverable?" An architecture document, a test report or a handover document from a past project (anonymized) shows how they really work.
Ownership and contract
- "Who owns the code and IP, and from when?" The answer should be you, from creation, in writing. Our guide to software IP ownership explains why "after full payment" or silence on the subject is a risk.
- "Whose accounts will hold the repositories, hosting and third-party services?" Yours. If the agency hosts everything in its own accounts, leaving becomes expensive.
- "Will you sign an NDA and, if you process personal data, a data processing agreement?" Under Article 28 of the GDPR, a processor handling personal data on your behalf must sign one. Professional liability insurance is also worth asking about.
Delivery
- "How is the work split into milestones, and how is each one accepted?" Look for milestones with written acceptance criteria and payment tied to delivery.
- "How do you handle changes in scope?" A good answer: changes are quoted in writing and approved before work starts.
- "How will we see progress?" Working software at regular intervals, not status reports alone.
- "What do you test, and how?" At minimum, automated tests on critical paths and a staging environment.
Continuity
- "What happens if your lead engineer becomes unavailable?" You want at least two people who know your project, plus documentation and code in your accounts.
- "How would another team take over if we parted ways?" A partner confident in its work will describe a handover process without hesitation.
How to check the answers
- Company registry. For a French company, look it up on annuaire-entreprises.data.gouv.fr to see its legal form, registration date and directors. Compare it with what the agency tells you; a young company can be a sound partner, but the story should match.
- Public profiles. Check that named engineers exist, have relevant experience and list the agency.
- A reference call. Ask the past client about communication, how problems were handled and whether they would hire the team again.
- Independent reviews. Google Business Profile, Clutch or LinkedIn recommendations, read for specifics rather than stars.
- A paid discovery phase. Two to four weeks of real work (requirements, architecture, data model, milestones, estimate) is the best predictor of how the build will go, and you keep the plan either way.
Red flags
- The people on the sales call are not the people who will build your product, and nobody will say who is.
- A firm price and timeline before anyone has asked about your users, data or integrations. See what drives the cost of a custom web application.
- Code, hosting or domain names registered in the agency's accounts.
- No written acceptance criteria, or "we'll know it when we see it".
- Reluctance to sign an NDA or a data processing agreement.
- No answer to "how would someone else take this over?"
A short contract checklist
- Assignment of IP to you, in writing, covering source code and documentation
- Repositories, hosting and third-party accounts in your name
- Milestones with scope, acceptance criteria and payment on delivery
- Written process and pricing for change requests
- NDA and, where relevant, a GDPR data processing agreement
- Named team and an obligation to tell you about changes
- Maintenance terms with response times, or a defined handover
- Exit clause: what you receive and how quickly if you end the contract
Frequently asked questions
How long should vetting take? One to three weeks: a first call, a technical conversation with the engineers, a reference call and a contract review. A paid discovery phase adds two to four weeks but replaces much of the guesswork.
Should I choose the cheapest agency? Choose the one whose answers you can verify. A low quote that leaves out testing, deployment or maintenance usually costs more by the end. Our comparison of agencies, freelancers and in-house teams covers the total cost of each model.
Is a young agency a risk? Not necessarily. Look at the people's experience, the contract terms and the reference, not only the registration date. What matters is that you are protected if something goes wrong.
We designed our own contract terms around these questions, and our buyer FAQ answers them for FNB Solutions. If you are comparing partners for a custom web application, start a conversation and ask us all fifteen.
Sources
- GDPR Article 28: Processor
- Annuaire des entreprises, the French government's public company directory