The 12 Questions That Expose a Weak Software Vendor Before You Sign Anything

Who actually writes the code, what happened on their last failed project, and what you keep if you part ways. A vetting checklist written from the other side of the table — with the answers that should end the meeting.

The person who sells you the project is almost never the person who writes it. That gap—between the pitch and the keyboard—is where most software relationships quietly rot. A contract won't protect you from it. The right questions, asked before you sign, will.

A weak vendor rarely lies outright. They give you smooth answers that fall apart the moment you ask a second question. Below are the twelve we'd want a client to ask us—the ones that separate a team that ships from a team that sells. Not one of them is about price.

Who actually writes the code?

Ask for the names and seniority of the people who will be on your project, not the agency's headline roster. Plenty of shops win the deal with senior architects and then hand the build to juniors or an offshore subcontractor you were never told about. That isn't always bad—but you deserve to know before, not after.

• Who writes the code specifically, and how many years have they done this?
• Is any part of this subcontracted or offshored? To whom, and where?

What happened on your last project that went wrong?

Every team with real mileage has a project that went sideways. A vendor who claims a perfect record is either new or not being straight with you. What matters is the story: what broke, whether they saw it coming, and what they changed afterward.

• Tell me about a project that blew its deadline or budget. What caused it?
• What do you do differently today because of that?

Listen for ownership. "The client kept changing the requirements" is a red flag—managing scope change is the vendor's job. "We underestimated the data migration, so now we estimate it as its own line item" is a team that learned something.

What do you keep if we part ways?

Assume the relationship ends—badly, mid-project—and reason backward. If you can't walk away with a running system, you don't have a vendor, you have a hostage situation. Get these answers in writing.

• Do I own the source code and all IP outright, or do you license it to me?
• Whose name is on the cloud accounts, the domains, and the repositories?
• If we stop today, can another team pick this up from the repo and a README?

Be wary of anyone who hosts your production system in their own AWS account, or who keeps the code on their machines until the final payment clears. Lock-in through custom infrastructure—home-grown build tools, undocumented deploy steps—costs more to escape than it ever saved you.

How do you estimate, and what happens when scope changes?

A fixed-bid quote for anything longer than a few weeks is usually fiction: either padded 40-60% to cover the vendor's risk, or lowballed to win the deal and clawed back through change orders. Ask how they reached the number, and how they'll handle the inevitable moment the plan meets reality.

• How did you arrive at this figure, and what's your confidence range?
• What's your process when we need something that wasn't in the original scope?

How do you know when something actually works?

"Done" means different things to different teams. For a serious one it means tested, reviewed, and running in production-like conditions. For a weak one it means it worked once on the developer's laptop. You don't need 100% test coverage—chasing it wastes money. You need automated tests on the parts that hurt when they break—payments, authentication, data integrity—and a pipeline that runs them on every change.

• What's tested, and does every change run through CI/CD before it ships to production?

Where does AI actually belong here—and where doesn't it?

Right now every vendor claims to be AI-native. The honest ones will tell you where a language model helps and where it's the wrong tool. If someone proposes an LLM for something a database query and a plain rule would do more cheaply and reliably, they're selling a trend, not solving your problem. AI features fail differently from normal code—they're probabilistic. A team that can't tell you how they measure accuracy or catch regressions is shipping something it can't control.

• Which parts genuinely benefit from AI, which are better as plain code, and how do you evaluate the quality of the AI output—do you run evals or just eyeball it?

Who do I talk to, and how often?

The fastest predictor of a bad project is silence. Ask who your point of contact is, how often you'll see working software—not slides—and what happens when something breaks at an awkward hour. A team that shows you a deployed increment every week or two has nowhere to hide, which is exactly what you want.

• Will I see a working, deployed increment every one to two weeks?

The tell isn't the answer—it's the follow-up

You don't need to be technical to run this checklist. The pattern is simple: ask the question, then ask one more about the answer. A strong vendor gets more specific under follow-up—more names, more caveats, more detail about what could go wrong. A weak one gets vaguer, more defensive, or steers back to price. Trust that reaction more than any reference or portfolio. The team that answers hard questions honestly before the contract is the same one that will tell you the truth after it.