Sales calls tend to answer the questions the vendor wants asked. The questions below are the ones that show how a team actually works: how it estimates, who writes the code, what happens when plans change and what you walk away with at the end. Any vendor, us included, should be able to answer them in writing.
These are the questions to ask a software development company before you sign anything. You do not need all fifteen on a first call. Send them in writing to your shortlist, compare the answers side by side, and pay attention to how specific each reply is.
How to read the answers
A good answer names a tool, a step, a person or a number of days. A weak answer uses words like "flexible", "agile" and "best practices" without saying what happens on a Tuesday afternoon when something breaks. Vague is not always dishonest, but it usually means nobody has thought about it yet.
If your idea is commercially sensitive, ask for a non-disclosure agreement before you share the details. We sign one before a project starts, and a reluctant vendor at this stage is worth noting.
Questions to ask a software development company about the work
1. Can you show me something similar that is running today?
Screenshots can be mockups. Ask for a live site or an app you can install, and ask what that team built versus what was bought in. Our own portfolio of delivered projects is there to be questioned in exactly this way.
2. What would you change or cut from my plan?
A team that agrees with every line of your brief has not thought hard about it. You want someone who says, for example, "leave the loyalty points out of version one and see whether customers ask for them."
3. What is not included in this quote?
This is the single most useful question on the list. Common exclusions: hosting, app store fees, content entry, third-party licenses, the admin panel, testing on real devices, and bug fixes after launch. A careful vendor lists assumptions and exclusions without being asked.
4. How do you test, and who does it?
If the answer is "the developers test their own work", expect your customers to find the bugs. Ask who writes the test cases, whether critical flows such as login and payment have automated tests, and which real devices and browsers they check. Ask to see what a bug report from their testers looks like.
About the people and the process
5. Who will work on my project, and can I talk to them?
Ask for names and roles, not a team size. Find out whether you can speak to the developers directly or only through an account manager. Our clients talk directly to the engineers on their project, because every hand-off between people is a place where details get lost.
6. What happens if a key developer leaves?
People leave. What matters is whether anyone else understands the code. Listen for code reviews, written documentation and a second developer who knows each part of the system.
7. How will I see progress?
The answer you want is a build you can use yourself every week or two, not a percentage. "Eighty percent done" in a status report can stay eighty percent done for a month.
8. What do you need from me, and how quickly?
Projects slip on the client side as often as the vendor side: content that arrives late, decisions nobody makes, feedback that takes two weeks. A good vendor tells you up front what it needs, such as a decision-maker, logins and review turnaround within a set number of days.
9. How do you handle security?
You are not looking for a lecture. You are looking for specifics about your app: how user roles and permissions are enforced, where passwords and API keys are stored, how dependencies get updated. A developer should be able to discuss the risks in the OWASP Top 10, where broken access control heads the 2025 list, in terms of your own screens and data.
About money and changes
10. Which pricing model are you proposing, and why this one?
Fixed price, time and materials and a dedicated team each suit different situations. The answer should connect to your project: how settled the scope is, how long the work runs, how much you expect to change. Our comparison of fixed price, time and materials and dedicated teams explains when each one fits.
11. How do you handle changes once we start?
You will change your mind; everyone does. Look for a written process: a change request, an estimate in hours or money, your approval, and then the work. Verbal "we'll squeeze it in" arrangements feel friendly and end in disputes.
12. Can we start with a small paid piece of work?
One paid milestone, such as a prototype or a single working feature, tells you more about a team than any proposal. We offer this, so you can judge the work before committing further. A vendor who insists on a large upfront payment for the whole project is asking you to take all the risk.
About ownership and the end of the project
13. Who owns the code, and when do I get repository access?
The contract should say you own the code you paid for, and you should have access to the repository from the first week, not at the end. With us, the client owns the source code and has repository access. If the company is offshore, check how ownership is assigned under its local law; our guide to hiring developers in India covers what the assignment should say.
14. Whose name will the accounts be in?
Domain, hosting, app store developer accounts, payment gateway, analytics. All of these should be registered to your business, with the vendor given access. Moving an app between store accounts later is possible but slower than getting it right on day one.
15. If we stop working together, what do I get and how fast?
Ask for it in the contract: code, database export, credentials and documentation within a fixed number of days, and a short handover call for whoever comes next.
Two quotes for the same app, compared
Imagine a veterinary practice with three vets that wants online booking. It sends the same brief to two companies.
Company A replies within a day: $14,000, six weeks, a one-page proposal. Company B takes four days, asks eleven questions, and comes back at $21,000 over nine weeks with a page of assumptions.
The practice asks both question 3. Company A's answer: the price covers the booking screens pet owners use. The staff calendar, SMS reminders, deployment to the practice's hosting and fixes after launch are extras at $45 an hour. Company B's quote already includes all four.
When the practice estimates those extras with Company A (say 120 hours for the calendar and reminders, 20 for deployment, 30 for post-launch fixes), the total is about $21,650. The quotes were never $7,000 apart. They were describing different projects. Comparing scope first and price second is the whole point of asking these questions.
Answers that should make you pause
- A firm price for a vague brief, with no questions asked.
- No access to the code "until the final payment".
- App store accounts or hosting set up in the vendor's name "to save time".
- Every feature described as easy.
- Pressure to sign this week because of a discount.
None of these proves a company is bad. Each one is a reason to ask a follow-up before you commit.
Start by sending questions 3, 12 and 13 to every company on your list. Those three alone will tell you how carefully each one has read your brief, how much risk it expects you to carry and what you will own at the end.
If you would like to put all fifteen to us, send them with your project brief. We reply to every enquiry within 24 hours, and if we work together you deal directly with the engineers building it.
