How many software development companies should I talk to before choosing one?

Enough to compare answers, not so many that every call blurs into the next. Three is usually the right number for a first shortlist. Send each the same brief, ask each the same questions, and compare the written estimates side by side. If all three give wildly different scopes, the brief is probably too vague, and fixing that will do more good than talking to a fourth vendor.

What is a red flag when hiring a software development agency?

A price given before anyone has asked about your users, data or integrations. Other warning signs are vague answers about who owns the code, no access to the repository until the final invoice is paid, a team that cannot be named, no written plan for testing, and references that turn out to be logos rather than people you can actually call. Any one of these is worth a direct follow-up question.

Should I ask a software company for a fixed price?

Ask for whichever model fits how well your scope is understood. A fixed price works when the scope is written down and unlikely to change. Time and material, billed per sprint, works better when you expect to learn as you build. The useful question is not which model they offer but how they handle change requests under it, because every project has some.

Is it reasonable to ask for a paid discovery phase before the full project?

Yes, and for anything larger than a small tool it is often the safest way to start. A short discovery phase turns your idea into a written scope, a set of user flows and an estimate you can hold the vendor to. It also gives you a low-risk way to see how the team works before you commit to the build. Make sure you own what it produces, so you could take it elsewhere.

Questions to Ask a Software Development Company

The questions to ask a software development company are not the forty on a typical checklist. They are the ten that reveal how the team plans, who owns what you pay for, what happens after launch, and whether past clients would hire them again. Ask those, listen to how the answers are given as much as what they say, and you will know more after one call than after a week of reading portfolios.

Most lists of questions to ask a software development company, or any agency, are long because they try to cover every possible vendor. You do not need that. You need questions that a weak vendor struggles to answer well and a good one answers without hesitation. That is what the list below is built for.

The ten questions to ask a software development company

Here is the short list. The sections after it explain what a good answer sounds like for each.

Area	Question	What it surfaces
Understanding	1. What would you need to know before giving us a price?	Whether they estimate from evidence or from hope
Process	2. What does a typical two-week cycle look like for us?	How often you see working software
Process	3. Who exactly will work on this, and who do we talk to?	Seniority, continuity, single point of contact
Process	4. How do you handle a change in scope halfway through?	Whether change is priced fairly or used as leverage
Quality	5. How do you test, and what do we see before a release?	Whether testing is planned or improvised
Ownership	6. Who owns the code and IP, and when?	Your rights if the relationship ends
Ownership	7. Will we have access to the repository and hosting from day one?	Whether you could walk away with your system
Ownership	8. What do we get at handover?	Documentation, credentials, deployment notes
After launch	9. What happens after launch, and what does support cost?	Whether the price includes the second year
Evidence	10. Can we speak to two clients whose projects resemble ours?	Real outcomes, not logos

If you only have time for three, ask 1, 6 and 10. Those are the ones where the gap between a good and a poor vendor is widest.

Questions about process and sprints

Of all the questions to ask a software development company, the process ones tell you how the next six months will feel. A team that cannot describe its own process clearly will not run yours clearly either.

What would you need to know before giving us a price?

A good vendor answers with questions of its own: who the users are, what data you already hold, which systems it has to connect to, what happens today without the software. A vendor that quotes from a one-paragraph email is guessing, and guesses get corrected later through change requests. If you have not written a brief yet, our guide on how to write a software project brief covers what to put in it so every vendor quotes against the same thing.

What does a typical two-week cycle look like?

Listen for working software at the end of each cycle, not status reports. We run two-week sprints: a planning session at the start, a demo of working features at the end, and a short list of decisions we need from you. Whatever the rhythm, you should be able to say on any given Friday what was built, what was shown and what is next.

Who exactly will work on this?

Ask for names and roles, and ask whether those people stay for the whole project. The common failure is a senior engineer on the sales call and a rotating cast on the build. Also ask who your single point of contact is, and how quickly they normally reply.

How do you handle a change in scope?

Every project changes. The question is whether there is a written way to agree the change, price it and adjust the timeline before work starts on it. Vague answers here are the main source of budget disputes later. If the vendor is proposing a long-running team rather than a fixed project, our explainer on the dedicated development team model covers how scope and change usually work under that arrangement.

Questions to ask a software development company about IP and handover

These are the questions to ask before hiring a software developer that people most often skip, because they feel awkward. They are also the ones that matter most if anything goes wrong.

Who owns the code and IP, and when? The answer you want is simple: you do, with ownership transferring as you pay, written into the contract. Watch for clauses that keep ownership with the vendor until a final payment, or licence you the code rather than assign it, or reserve rights over "reusable components" without defining them.

Will we have access to the repository and hosting from day one? You should. The repository should sit in an account you control, or be transferred to one, and cloud hosting should be billed to you or clearly handed over. If the only copy of your system lives in the vendor's account, you do not really own it, whatever the contract says.

What do we get at handover? Ask for a concrete list: source code, database schema and migrations, environment and deployment notes, credentials for every third-party service, and a short written explanation of how the system fits together. A team that writes this as it goes will produce it easily. A team that has never been asked will struggle.

Questions to ask a software development company about support

Launch is the start of the system's life, not the end of the project. When you vet a software vendor, ask what happens in the weeks and months after go-live.

Is there a warranty period for bugs, and what counts as a bug? Get the definition in writing.
What does ongoing support cover? Security patches, dependency upgrades, hosting, small changes and new features are different things, and a retainer may cover some and not others.
How is support priced? A monthly retainer, a pool of hours, or ad hoc invoices each suit different situations. The worst answer is "we will sort that out later".
If we move support to another team, will you help? A confident vendor says yes, because a clean handover is what they would want if they were taking over.

We offer support on a monthly retainer for the systems we build, and we say so up front, because the second year of a system's cost is part of the decision you are making now.

How to read the answers

The answers matter, but how they are given tells you nearly as much. When you put these interview questions to a development company, notice the following.

Specific beats confident. "We usually start with a two-week discovery and you get a written scope, user flows and an estimate" is a better answer than "we are very flexible". Specific answers can be checked later. General ones cannot.

Questions back are a good sign. A vendor that asks about your users, data and constraints while answering your questions is already doing the work. One that only talks about itself is selling.

Watch for hesitation on ownership. Process answers can be honestly vague early on. Ownership answers cannot. If "who owns the code" produces a pause, a reference to "standard terms" or a promise to check, treat that as the most important thing you learned.

Compare in writing. After the calls, ask each vendor to put their approach, timeline and estimate in writing. A list of questions to ask a software development company only helps if you can line the answers up side by side.

A simple way to score the calls is to mark each of the ten questions as clear, vague or avoided. Two or more "avoided" answers is usually enough to drop a vendor, however good the portfolio looks.

Questions to ask their references

References are the most underused part of choosing a vendor, and the questions to ask a software development company's past clients are different from the ones you ask the company itself. A logo on a website tells you a project happened. A conversation tells you how it went. Ask for two clients whose projects resemble yours in size or type, and then ask them:

What did you hire them to build, and is it still running?
Did the project finish close to the original estimate? If not, why not, and how was that handled?
How did they handle disagreements or bad news?
Do you have full access to your code and hosting today?
Are they still supporting the system, and if not, why did that end?
Would you hire them again for something that matters?

The last question is the one to listen to most carefully. A pause before "yes" is information.

Choosing who to hire

Asking the right questions to ask a software development company is not about catching anyone out. Good vendors like these questions, because they make it easier to show how they work. The aim is to leave each call knowing how the team plans, who owns the result, what the second year costs, and what past clients really think.

If you would like to see how we answer them, book a free 30-minute discovery call. A senior engineer talks your project through with you, and a written approach, timeline and estimate follow within two business days. You can read more about how we run custom software development projects, including ownership of code and IP, before you call.

Ten questions to ask a software development company before you sign