Every software vendor’s website says the same three things: experienced team, on time, on budget. None of that tells you anything, because every vendor says it whether or not it’s true. The questions below are the ones that actually separate a project that ships from one that doesn’t. Ask them before you sign anything.
“What happens if I ask for a change mid-project?”
This is the single best predictor of how a project will actually go. A vendor who says “we’ll figure it out” is telling you scope changes will be handled informally, which means they’ll either get absorbed silently (and show up later as a missed deadline) or become a fight. A vendor who can describe a specific process, including how a change gets costed, who approves it, how it affects the timeline, and how fast you’ll hear back, is telling you they’ve dealt with this before and built a system for it.
“Who exactly will be on my project, and do they rotate?”
Ask for names, not job titles. Then ask what happens if someone leaves or gets pulled onto another client mid-project. Team rotation is one of the most common, least-discussed causes of slipped deadlines: every new person needs weeks to rebuild context that was never written down. A vendor with a fixed team from day one is making a real commitment. A vendor who says “we’ll assign resources as needed” is describing a staffing pool, not a team.
“Can I see documentation from a past project, not just a marketing case study?”
A case study is written to sell you. A requirements document, an architecture diagram, or a QA checklist from a real past engagement shows you what the vendor actually produces when no one but the client is reading it. If a vendor can’t or won’t share a redacted example, that’s information too.
“What’s the plan if the deadline is at risk?”
Every project hits a moment where the original date looks unlikely. That part is normal; it happens to every vendor. What separates them is how early they see it coming and what they do about it. Ask specifically: at what point in a sprint would you tell me a date is slipping, and what would you show me to prove it? A vague answer here usually means the first time you’ll hear about a delay is when it’s already too late to do anything about it.
“What do I own when this is finished?”
Get this in writing before you start, not after. Source code, documentation, design files, and any third-party accounts set up during the build should all be explicitly yours on completion, not something you have to request or negotiate for later. Vendors who build in soft lock-in, such as proprietary frameworks, withheld credentials, or undocumented systems, are betting on you needing them again. That bet shouldn’t be the one you’re financing.
“What don’t you do?”
The most useful thing a vendor can say is “someone else would be a better fit for this.” A vendor who claims to be equally strong at everything, from discovery to design to development to marketing to ongoing support, is either unusually well-resourced or overselling one of those. Either way, you want to know before the contract is signed which parts of the work are their real strength and which parts they’re stretching to cover.
None of these questions are about price, and that’s deliberate. Price differences between qualified vendors are usually smaller than they look once you account for rework, missed deadlines, and the cost of a rebuild two years later. The questions above are the ones that tell you whether you’re buying a plan or a promise.
If you’re in the middle of comparing vendors and want a second opinion on what you’re hearing, that’s a fair use of the free 30 minutes: info@femmesoft.us or +1 484 978 0339.