35 Questions to Ask a Software Vendor Before Signing a Contract

When looking for a software vendor, most clients lead with two questions: “How much will it cost?” and “Have you done something similar?” That’s not enough. They skip the questions that actually matter: risk assessment, SLAs, code ownership, incident response. The result is predictable. Problems start early, but they don’t usually surface until months later…

This guide covers what to ask during sales calls and how to tell a good answer from a rehearsed one.

One request before we dive in: don’t ask all of these questions in a single meeting. Have mercy on the sales rep.

Questions About the Development Process and Communication

The way a vendor plans and ships features will shape not just the budget, but the outcome of your entire project. Look for proof that they have a repeatable process, not a promise to “quickly throw developers at it.”

How Many Hours Per Week Will You Need From My Side?

Ask: “How many hours per week do you need from me and my team? For what exactly?” A good vendor knows the project won’t work without your regular involvement. Expect a few hours a week: that’s what planning sessions, progress reviews, and product decisions add up to. Skip that, and the vendor ends up guessing instead of building what you actually need.

What Should I Expect in the First 60 Days of Working Together?

The answer should include specifics: how the team collects and validates requirements, what “done” means to them (Definition of Done), and whether CI/CD goes live from day one, not “somewhere down the road.” Every project’s first weeks follow a similar rhythm, so the vendor should already have a playbook for this. If you get vague generalities, push back. If that gets you more of the same, it might be time to look elsewhere.

How Do You Gather Requirements and Make Sure You Understand My Business?

A company that immediately “locks the team in a room and starts the meter” without understanding your business is a warning sign. Ask directly: “How will I know you truly understand my goal before you start writing code?” A solid vendor validates your business assumptions first (through something like Definition of Ready) before writing a single line of code.

How Will I Know the Project Is Delivering on My Business Goals?

Many teams track progress in story points and closed tickets. The problem? You can check off dozens of tasks per sprint and still not ship a single useful feature. This question reveals whether the vendor gets the purpose of your product, or just writes code because you’re paying for it. You should see working software at the end of every sprint and be able to judge for yourself whether it’s actually moving you closer to your goal.

How Often Will New Changes Reach Production?

This is really about CI/CD: continuous integration and continuous deployment. A mature team ships changes often and mostly on autopilot: code passes through automated tests, gets reviewed, and hits production without anyone touching it by hand. If deployments are “a big event done manually once a month,” that’s a red flag.

Who Sets Priorities, and Can We Change Them Mid-Sprint?

Every software company calls itself “Agile.” This question checks whether that label means anything. Ask: “What if a market opportunity suddenly appears and I want to change the goal of the current sprint?” A good vendor will tell you reprioritizing is possible even overnight, as long as both sides understand the trade-offs. They’ll walk you through how they’ve handled it before. A weak vendor will assure you it’s absolutely doable, but won’t mention trade-offs or specifics.

Questions About Team Competence and AI Adoption

You’re paying for the expertise of real people, not a brand name. You have every right to know who’s actually going to build your product before you commit.

Have You Worked on Projects in My Industry?

A standard question, but most clients ask it the wrong way. “Have you done anything in my industry?” won’t get you far, because everyone will say “yes.” Dig deeper: “What was your biggest project in this industry, how many people worked on it, how long did it last, and does anyone from that team still work at your company?” That last part is key. It tells you whether the know-how from that project is still in the building, or walked out the door years ago.

Can I Talk to a Client You’ve Worked With on a Similar Project?

Few clients bother asking for references, yet it’s the cheapest and most reliable way to check whether a vendor actually delivers on their promises. Ask: “Can you connect me with a client from my industry that you’ve worked with in the last two years?” Make sure to ask for a recent client too, because a reference from three years ago may have little to do with the company today. NDAs as an excuse? That’s understandable. But if they can’t put you in touch with any happy client, draw your own conclusions.

What Is Your Technology Stack?

If you’re not technical, this question might feel like it’s not for you. But the tech stack has a direct impact on how easily you’ll find developers later, whether you’re scaling the team or switching vendors. Ask: “What technologies do you work with, and can you show me a sample architecture from a similar project?” This matters even more if you already have a technical team the vendor will work alongside, or if you plan to bring the system in-house later.

Pay attention to how the vendor responds when asked about a technology they don’t have experience with. A company that openly says “we’re not deep in that stack right now, but here’s what we can do” earns more trust than one that claims to be an expert in everything.

Can I Talk to Your Tech Lead Before Making a Decision?

Sales meetings mean talking to salespeople. But they won’t be the ones writing your code. Ask: “Before I decide, can I speak with the Tech Lead, PO, and engineer who will actually be working on my project?” Think of this as a stealth interview. You’re testing whether the sales pitch holds up when you meet the people who’ll actually work on your project day to day.

Once you’re talking to them, watch for a few things. Do they ask sharp questions about your business, or just nod along? Can they explain their approach without hiding behind jargon? Will they push back on your assumptions if they spot a flaw? You’re looking for partners, not yes-men. If the Tech Lead agrees to everything but never asks “why?”, that’s a bad sign.

How Many on the Team Are Your People, and How Many Will You Need to Hire?

If a company positions itself as experienced, you have every right to ask whether the team is actually made up of their people. Find out how many developers have been with the company for a while and how many will be hired specifically for your project. Ask about the seniority mix too. If it turns out two-thirds of the team hasn’t been recruited yet, that’s a red flag. You won’t get a team. You’ll get a group of strangers learning to work together. On your dime and on your project.

Who Owns Architecture Decisions, and How Do You Manage Technical Debt?

Poor architectural choices early on are like structural defects in a building: the later you find them, the more expensive the fix. Technical debt (deliberate shortcuts in code) compounds every week. If nobody keeps it in check, every new feature takes progressively longer and costs progressively more. Ask: “Who will personally be making key architectural decisions, and how do you manage technical debt?” You want a specific person with a name, not “the whole team decides together.”

How Quickly Can You Replace a Key Developer?

People leave projects. That’s inevitable. The question is what happens next. Ask: “How quickly can you provide a competent replacement when a key developer leaves the project?” You want to hear a specific timeframe (days, not weeks) and find out whether the company has a bench of available developers in the right technology. Also ask about knowledge sharing within the team. If everything about the project lives in one person’s head, their departure could set you back months.

Can I Vet Your Team’s Skills Before We Start?

This comes down to transparency. Ask: “Can my CTO or an external consultant conduct a brief technical interview with the key people on the team?” Think of it as a litmus test. A company that hires well won’t have a problem with it. Pushback or evasive answers should tell you a lot.

What Does Your Recruitment and Onboarding Process Look Like?

A software company is only as good as its processes. If there’s no proven way to vet and onboard new people, quality will suffer sooner or later. And even if the company as a whole runs fine, your project might be the one that takes the hit. Ask: “How do you vet new hires and train them on your standards?” The line “we only hire seniors” means nothing without concrete recruitment, onboarding, and quality control processes to back it up.

Do You Have Experience With Project Rescue?

Why even ask this? Most companies can build a system from scratch. But stepping into someone else’s neglected codebase, auditing it, and getting things back on track is a completely different game. A company with real rescue experience has to have solid processes and standards. Without them, no rescue mission works. Ask: “What does your process look like for taking over projects started by someone else?” If you hear a concrete playbook (audit, stabilization, remediation plan), that’s a good sign. If the answer is “we’ll figure it out,” keep looking.

How Do You Use AI in Your Development Process?

A handful of developers using Copilot or Claude Code on their own doesn’t move the needle at the company level. What matters is whether the company has adopted AI as part of its process, not as a side experiment. Ask: “Do you have standardized guidelines for using AI in your development process?” You’re after specifics: internal guidelines for developers, rigorous review of AI-generated code, quality gates. A company that says “everyone uses whatever they want” is treating AI as a toy, not a production tool.

Questions About Pricing and Cost Optimization

Money questions aren’t just about negotiating. They reveal whether the vendor understands your financial reality and can recommend the best path within your budget, not just count hours and send an invoice.

What Would You Cut From the Project if We Had to Trim the Budget?

Ask: “If we had to cut the budget by 30%, what would you drop and why?” This is a stress test. A good vendor will suggest cutting features that matter least to your product’s value. You might discover that tweaking a single requirement (say, accepting slightly longer data processing times) could slash infrastructure costs. A weak vendor will either dodge the question entirely or give you a vague “we’d need to look into that” without explaining how they’d approach the analysis. A good vendor, even if they don’t have the answer yet, will show you how they think: “we’d map each feature to business value and cut from the bottom.”

Which of My Requirements Have the Biggest Impact on Price?

A vendor who can clearly explain what’s driving the biggest costs genuinely understands your problem. The key word is “why.” If you hear a specific answer (for example, “supporting multiple languages in the first version will double development time, better to start with one”), you’re talking to someone who has actually analyzed your problem. If all you get is a lump sum with no breakdown, the vendor either doesn’t understand what you’re building, or doesn’t want you to see where the money goes.

What Will a Pause in Development Cost Me?

Not every project runs nonstop. Sometimes you need to pause for a few months while raising another funding round or waiting on a board decision. Ask: “What costs will I face if we pause development for two months?” You want to know whether the company charges a retainer to keep the team on hold, or whether you’ll have to let them go and pay for re-onboarding when you restart. Either way, it’s a real cost that belongs in the budget from day one, not a surprise halfway through.

How Will We Handle Billing? (Time and Materials vs. Fixed Price)

Some companies offer both models, others specialize in one. Ask: “What billing models do you offer, and which one do you recommend for my situation?” Here’s the short version: Fixed Price means a set price for a set scope. You get budget predictability, but every change in requirements means renegotiation and contract amendments. Change your mind halfway through? Prepare for paperwork. T&M (Time and Materials) means paying for hours worked. Full flexibility, but you need to keep an eye on what the team spends time on. Without that, it’s easy to burn 80% of the budget and deliver only 40% of the scope.

Watch for how the vendor frames the recommendation. Do they explain the trade-offs of each model for your specific situation, or just push the one that gives them more predictable revenue? A vendor who points out the downsides of their own recommendation earns extra trust points.

Questions About System Maintenance and Security

Building the software is usually the smaller part of what you’ll spend over its lifetime. The real money goes to maintenance and modernization. Think of defense contracts: a tank costs a fraction of its 20-year service package. Software works the same way. These questions test whether the vendor thinks about your product with that long game in mind.

Who Will Keep the System Running After Launch?

“We’ll figure it out” is something we hear surprisingly often. But launch isn’t the finish line. It’s when things get real: the system is live, users depend on it, and development continues alongside production support. A production bug becomes a fire that needs to be put out fast, ideally without disrupting ongoing development. Ask: “What does your post-launch support model look like? Who fixes bugs and on what terms?” A strong answer includes specifics: a monthly hours package, a dedicated contact person, guaranteed SLAs. A bad answer is silence or “we’ll sort that out later.” If the vendor doesn’t have a clear answer ready, they probably don’t have a clear process either.

How Will You Respond to Issues Outside Business Hours?

This builds on the previous question. Once you know who handles support, you need to understand how fast they react when nobody’s in the office. Many companies work strictly 9-to-5. If your system serves customers on weekends (an e-commerce store, for example), a Sunday morning outage isn’t a “minor inconvenience.” It’s real revenue lost. Ask: “How do you monitor the system and how fast will you respond outside business hours?”

You want to hear about automated monitoring and alerting, not just someone checking dashboards during office hours. A strong answer includes an on-call rotation, clearly defined severity levels (a full outage vs. a minor UI glitch shouldn’t trigger the same response), and a communication plan so you know who calls you and when.

Three acronyms worth knowing. SLA is the maximum response time to an incident (say, 15 minutes). RTO is how long the system can stay down before it needs to be back. RPO is how much recent data you’re willing to lose in a worst-case scenario. Also ask what happens when the vendor misses these targets. Contractual penalties for SLA breaches are standard practice, not a luxury.

What Happens When the System Goes Down?

The previous two questions covered who’s responsible and how fast they respond. This one goes deeper: what actually happens to your business when the system goes down. It’s not about whether the server reboots. It’s about whether orders, customer data, and integrations survive the outage intact. Ask: “If the system crashes, what happens to orders, customer data, and integrations with external platforms?” A well-prepared vendor designs the architecture so that when one module fails, the rest keeps running and data lands in a buffer instead of vanishing. If the only answer you get is “we’ll bring the server back up,” that’s not enough.

Where Will My Data Be Stored and Who Will Have Access?

Data security can make or break a business, yet clients rarely bring it up before signing. Ask: “Where will my data be physically stored, who will be able to see it, and what does your backup and disaster recovery policy look like?” Here’s what you want to hear:

• Server location (especially if you’re subject to GDPR),
• Exactly who will have access to your users’ data (the vendor’s developers? the cloud provider? third parties?),
• Backup frequency and testing procedures,
• A plan for data loss scenarios.

If the vendor doesn’t have a clear answer, data security probably isn’t built into their process. It’s handled on the fly.

What Will the Real Infrastructure Costs Be?

Cloud, server, and licensing costs tend to grow with your user base, and many clients only find out the hard way from the first invoice after launch. Ask: “Roughly how much will monthly infrastructure cost at our current scale, and how does that change when the user count grows tenfold?” A capable vendor can give you at least a ballpark, because they’ve run similar projects before. If they can’t even give you a rough number, they’ve either never managed infrastructure for a client, or haven’t taken the time to properly analyze your requirements.

Questions About Risk and Ending the Engagement

Most vendor conversations focus on what success looks like. Few people ask what happens when things go sideways, or when you decide to walk away. But it’s in a crisis and during a breakup that you find out who you’re really dealing with. A company that dodges these topics early on will dodge them during the project too.

Tell Me About a Project That Was Seriously at Risk

Every software house has had a rough project. If they say otherwise, they’re lying. Follow up: “What went wrong, and what did you change in the company after that situation?” You’re not looking for the polished version from the sales deck. You want facts: what actually went wrong, who decided on corrective action, and what the company changed to keep it from happening again. A good answer is a candid story with real lessons learned. A bad answer is “that’s never happened to us” or a story where the client takes all the blame.

When Was the Last Time You Didn’t Deliver on Time?

Nobody asks this, but everyone should. The question assumes it’s happened, and rightly so, because delays are normal in IT. Follow up: “What caused it and how did you handle it with the client?” An honest vendor will share a real story and tell you what they changed so it wouldn’t happen again. If you hear “we always deliver on time,” take that with a grain of salt.

What Do You Do When a Project Starts Falling Apart?

The previous questions dealt with the past. This one is about the future: your project. Ask: “What’s your procedure when something goes seriously wrong, like a key technical decision proving wrong, multiple team members leaving at once, or a major schedule slip?” You want to see a clear escalation path: who makes decisions under pressure, how quickly, and what communication with you looks like when things go critical. A company with experience knows how to de-escalate and keep the client in the loop. A company without it will improvise. And a project on fire is not the time for experiments.

How Will I Know the Project Is Going Off Track?

As a client, you usually find out about problems too late and at too high a cost. Ask: “How will you signal to me that something is wrong before I discover it myself?” A solid vendor doesn’t wait for you to start asking uncomfortable questions. They come to you first: “we have a problem, here’s the scope, and here’s our plan.” If the only answer you get is “we’ll send weekly reports,” that’s not enough. No report will save a project. What saves it is a person who picks up the phone and says “we have a problem” before that problem turns into a disaster.

How Do You Handle Scope Changes During a Project?

Scope changes are a fact of life in IT projects. New requirements, market shifts, lessons from user testing. The reasons are endless and no plan will eliminate them. Ask: “Tell me about a situation where you had to manage a major scope change. What did that look like?” In the answer, pay attention to three things:

• Who initiated the change (the client, the market, or the vendor spotting a problem),
• How quickly the vendor assessed the impact on timeline and budget,
• How they presented options and consequences to the client so they could make an informed decision.

A company that can tell this story in detail has a solid process behind it. A company that responds with generalities is probably winging it every time.

Will You Tell Me Straight if I’m the One Slowing the Project Down?

The vendor isn’t always the bottleneck. Sometimes it’s your own organization holding things up: delayed decisions, key stakeholders unreachable, requirements shifting every week. And here’s the thing: when your side is causing delays, you’re still paying for a team that can’t move forward. Ask: “What will you do if, after a few months, you conclude that the source of delays is on my side?”

You’re looking for more than just honesty. You want a process: how do they track blockers, when do they escalate, and do they come with a proposed solution or just a complaint? A vendor brave enough to say “the problem is on your end” and back it up with data and a plan is worth more than one who nods along to keep the peace and the invoices coming. You want a partner who cares about the project, not just the contract.

Can I Bring in an External Auditor During the Project?

If you don’t have your own technical team, an independent code audit is the only way to verify the quality of what you’re paying for. Without one, you have no idea whether technical debt is quietly piling up under the hood, ready to turn every simple change into a week-long ordeal six months from now. Ask: “Can I bring in an external consultant to review your code at any point?” A company that does quality work won’t mind. Resistance or deflection should raise a red flag, because it usually means there’s something to hide.

Who Will Own the Source Code?

Most clients assume that because they’re paying for development, the code belongs to them. Not necessarily. Without the right clause in the contract, IP rights may stay with the vendor. Ask: “When exactly will code ownership transfer to me, and will I have access to the repository from day one?” Ongoing repo access is your safety net in case the collaboration falls apart. If the vendor proposes handing over the code “at the end of the project,” pin down what that means, and what happens to the code if you walk away before the full scope is delivered.

What Happens if I Want to Switch Vendors?

Before you sign, make sure you can walk away. Vendor lock-in means you’re stuck with a provider because leaving would cost more than staying. It rarely happens on purpose. It creeps in through missing documentation, knowledge trapped in a few people’s heads, and code that reads like ancient hieroglyphics. Ask: “What would the process look like for handing the project over to another team or to my own company? How long would it take and what would I get?” The right answer is specifics: current technical documentation, a transition period with proper knowledge transfer, and code clean enough for a new team to pick up without a translator.

Questions You’re Better Off Not Asking

We’ve covered what to ask. Now let’s talk about questions you’re better off skipping. A bad question doesn’t just waste time. It can actively work against you, making you look like a client who’ll be hard to work with.

“Who Is Your Most Qualified Engineer?”

You’ll either hear “we have someone with 30 years of experience,” or get a deflection: “in which technology? Because we have a full-stack dev who’s worked in 10 languages…” Neither tells you anything about the team you’ll actually get. Ask about the people who will work on your project, not HR stats.

“Please Don’t Give Me a Heart Attack With That Price.”

An actual quote from a real meeting. The vendor has no way to respond to this, because they don’t control your budget. What they can do is help you match the scope to the money you have. So skip the commentary and ask what can be cut.

No Questions at All (a 40-Minute Monolog About Your Business)

True story. 40 minutes of a client explaining their 488% ROI trading strategy. Not one question. We nodded politely and left the call unable to quote a single thing. If you do all the talking, nobody learns anything. Especially you.

“Have You Done Projects in Fintech?”

“Yes. Next question.” That’s roughly all you’ll get. Generic questions get affirmative answers and zero useful information. Instead of “have you done anything in fintech,” go specific: “How did you build a system that’s PSD2-compliant?”, “What did your integration with a payment provider look like in a PCI DSS environment?” or “How did you handle KYC in a mobile app?” A simple “yes” won’t cut it with questions like these. The vendor has to tell a real story.

Where to Start Your First Conversation With a Software Vendor

If you only have 30 minutes, start with these six. The answers will tell you more than an hour of sales slides.

• Experience: “Show me a similar project and give me a direct contact for the client.”
• Process: “What should I expect in the first 60 days of working together?”
• Risk: “Tell me about a project that didn’t go well. What did you do about it?”
• Understanding the problem: “How do you gather requirements, and how will I know you understand my goal?”
• Meet the team: “Can I speak with a technical person from your team before I decide?”
• Critical thinking: “What concerns you most about this project?”

How to Choose a Software Vendor: Key Takeaways

We’ve covered a lot of ground, from processes and finances to crisis scenarios. Don’t skip any topic. Every one of them serves the same purpose: helping you avoid the costly mistake of signing with the wrong company.

But asking is only half the job. The other half is listening. Pay attention to details, push back when something sounds too smooth, and don’t judge each answer on its own. Judge the full picture they paint together. Anyone can nail one tough question. But by the tenth in a row, the gap between a vendor who truly knows what they’re doing and one who’s just good at selling becomes impossible to miss.

What comes after signing the contract?

Picking the right vendor is the foundation, but what you build on it depends on how you run the product from day one. Strategy, discovery, delivery quality, client alignment, team leadership: each of these areas shapes whether your product will be healthy and competitive a year from now, or quietly falling apart before you notice. Take care of your product’s health from day one with our 25-question product health checklist.