Questions to Ask a Software Development Company Before Signing

The five questions that reveal whether a software development company will deliver: "Who specifically will work on my project and what's their experience?", "Show me a project similar to mine — what went wrong and how did you fix it?", "What happens to my code if we stop working together?", "How do you handle scope changes mid-project?", and "Can I talk to a client whose project had problems?" Most buyers ask about timelines and rates. Those matter — but they tell you nothing about whether the company can actually ship production software that works a year after launch. The questions below do.

This guide covers the questions that separate companies with real engineering discipline from companies that are good at sales decks. Each section includes what a strong answer sounds like, what a red flag answer sounds like, and why the distinction matters.

What questions should you ask about the development team?

The single most predictive question you can ask is: "Who will actually write the code on my project, and what have they built before?" A company that answers with specific names, specific experience, and a clear team structure is telling you they have a stable team. A company that answers with "we'll assign the right resources" is telling you they staff projects from a bench — or worse, subcontract.

Follow up with: "Will these same people be on the project in six months?" Engineer turnover mid-project is the number one cause of budget overruns in outsourced development. When a senior developer leaves and a junior replacement needs three weeks to understand the codebase, you pay for that ramp-up — whether it appears on the invoice or not.

Ask about the team's experience with your specific technology stack and domain. "Have your engineers built a multi-tenant SaaS application before?" is a different question from "do you do SaaS development?" The first gets you a real answer. The second gets you a sales pitch.

How do you evaluate a company's track record honestly?

"Show me a project similar to mine" is the obvious question. The follow-up that matters is: "What went wrong on that project, and how did you handle it?" Every multi-month software project hits unexpected problems — data migration complications, third-party API changes, a requirement that turns out to be three times harder than scoped. What you want to hear is a specific story about a specific problem with a specific resolution.

A company that says "we delivered on time and on budget" for every project is either lying or hasn't done anything complex enough to encounter real problems. Neither is a good sign.

Ask to see the actual software running. Not a case study PDF — the live system. If they built an enterprise platform that digitised approval workflows, ask for a demo of the actual application. You can tell more about engineering quality from five minutes watching someone use the system than from an hour-long sales presentation.

Check how long their client relationships last. A company whose average engagement runs 12–18 months is different from one where most projects end at delivery. Long relationships mean the client trusts them enough to keep going — and that the code was good enough to extend rather than replace.

What questions reveal how they handle problems?

"How do you handle scope changes mid-project?" is the question that tells you the most about how the engagement will actually feel. In our experience running 50+ projects since 2017, scope changes happen in 100% of builds longer than three months. The question is never whether scope changes — it is how the company manages scope when it does.

A structured company will describe a change request process: the client raises a change, the team scopes the impact on timeline and budget, both sides agree before work begins. That takes a day, not a week. An unstructured company will say "we're flexible" — which means scope creep is invisible until the invoice arrives.

Two more questions in this category matter:

• "What does your escalation process look like when something is behind schedule?" A company with engineering discipline will have a defined escalation path — not just "the PM will let you know." You want to know who makes the call to add resources, cut scope, or extend timeline, and how quickly that decision gets made.
• "How do you do code reviews?" If the answer is "the team lead reviews before merge" — good. If the answer is a blank stare or "we trust our developers" — the code quality is inconsistent. Code reviews are the single cheapest quality control mechanism in software development. A company that skips them is cutting the one corner that costs you the most later.

What should you ask about IP and code ownership?

"What happens to my code if we stop working together?" should produce a one-sentence answer: "You own it. Full source code, documentation, and deployment credentials transfer to you." Anything more complicated than that is a problem.

The specific things to ask about IP and code ownership:

• Do you use proprietary frameworks or libraries that I'd be locked into? Some companies build on their own internal frameworks. If you leave, you either rewrite the framework-dependent code or stay. Ask explicitly whether the codebase uses standard open-source technologies or proprietary tooling.
• Where is the source code hosted, and do I have admin access? Your code should be in a repository you control — your GitHub or Bitbucket organisation, not theirs. If the code sits in their account, transferring it after a dispute becomes a negotiation instead of a right.
• Is there an IP assignment clause in the contract? The contract should state that all intellectual property created during the engagement belongs to you. Not "licensed to you" — assigned to you. This is non-negotiable for any custom software build.

The IP question is especially important for companies outsourcing development to India or other offshore locations. A clear IP protection framework in your outsourcing contract covers code ownership, NDA terms, and what happens during disputes. Get this right before the first sprint, not after the last one.

What questions expose hidden costs in software development?

The quoted price is never the full cost. The questions that expose the gap between the quote and what you actually pay:

A transparent company hands you a cost breakdown that includes everything: development hours, PM overhead, infrastructure, third-party costs, and post-launch support. A company that quotes only development hours and adds the rest later is not being dishonest — they are being strategic. Know the difference.

What red flag answers should disqualify a vendor?

Some answers should end the conversation. Not because the company is bad — but because the answer reveals a structural mismatch between what you need and what they can deliver.

Disqualifying answers, and why they matter:

• "We can start next week." A company with good engineers is busy. If they can staff a full team on seven days' notice, either those engineers aren't working on anything important, or they're pulling people off another client's project. Neither is good for you.
• "We've never had a project fail." Every company that has built enough software has had a project go wrong. A company that won't admit it is either too new to have been tested or too dishonest to learn from failure.
• "We don't do fixed-price contracts" — and also — "We don't do time-and-materials." A company that only works one way is inflexible. Different projects suit different models. A fixed-price engagement works for well-defined scope. Time-and-materials works when requirements will evolve. A company that refuses to discuss the model that fits your situation is protecting their margin, not your outcome.
• "We'll figure out the architecture as we go." Architecture decisions made in week one affect every sprint after that. Database schema, API structure, authentication model, deployment pipeline — these aren't things you iterate toward. They need deliberate upfront design. A company that doesn't do a discovery or scoping phase before writing code is building on sand.
• "Our developers are all senior." The industry average for senior engineers is roughly 20–30% of any team. A company that claims 100% senior staff is either redefining "senior" to mean "has written code before" or charging senior rates for mid-level work.

The question we get asked least — and it matters most — is "Can I talk to a client whose project had problems?" Any company can hand you a happy reference. The ones willing to connect you with a difficult project are the ones confident in how they handled it. At Madgeek, we have run 50+ projects over 8 years. Some went exactly to plan. Some hit hard problems — a data migration that was three times more complex than scoped, an API integration where the third-party documentation was wrong, a compliance requirement that surfaced mid-build. We will connect you with both kinds of clients, because how a company handles the hard projects tells you more than how they handle the easy ones.

How should you structure the vendor evaluation process?

Talk to three companies, not ten. Evaluating ten vendors means you spend five minutes on each. Evaluating three means you spend an hour — and an hour is what it takes to get past the sales layer and into how the company actually works.

Structure the evaluation in three stages:

1. Stage 1: Initial call (30 minutes). Ask the team composition and track record questions from this guide. If the answers are vague — stop here. You've saved yourself weeks.
2. Stage 2: Technical deep-dive (60 minutes). Ask to speak with the lead engineer or architect who would work on your project. Walk through a real technical challenge from their past work. You don't need to be technical yourself — listen for specificity. "We used Redis for caching because the query response time was 1.2 seconds and the client needed it under 200ms" is a different calibre of answer from "we optimised the performance."
3. Stage 3: Reference call (30 minutes). Talk to an actual client. Not a testimonial — a conversation. Ask them: "What went wrong, and how did they handle it?" and "Would you hire them again?" The second question is the only one that matters.

If you are evaluating whether to build custom software or work with an offshore development centre, these same questions apply — with extra weight on the IP, code ownership, and data security questions. Geography adds complexity, but the evaluation method stays the same: specificity over promises, proof over claims, references over case studies.

The companies that answer these questions well are not the ones with the best websites or the lowest rates. They are the ones willing to be specific — about who works on your project, what has gone wrong before, and what happens when it goes wrong again.