I’ve sat on both sides of this conversation more times than I can count — in the room pitching a company on a project, and in the room helping a client decide which vendor to trust with six figures and a critical piece of their business.
Here’s what I’ve noticed after enough of these conversations: the companies that make a bad hiring decision almost never do it because they didn’t ask enough questions. They do it because they asked the wrong questions — the kind that are easy to answer well in a sales call but tell you almost nothing about how the company actually works once the contract is signed.
“Do you have experience in our industry?” Everyone says yes.
“Can you meet our deadline?” Everyone says yes.
“Will you deliver quality work?” Everyone says yes.
None of these questions separate a serious partner from a company that’s good at sales calls. The questions below are different. They’re designed to surface how a company actually operates — their process, their honesty, their risk tolerance — not just what they’re willing to promise you in a pitch.
I’ll be direct about something else too: no vendor will have a perfect answer to all 15 of these. That’s not the goal. The goal is pattern recognition — are they thoughtful and specific, or vague and reassuring? That difference tells you more than any portfolio.
Quick Answer
Before signing with a software development company, ask about their discovery process, how they handle scope changes, who actually owns your code and IP, how they staff and replace team members, what their QA process looks like, how they communicate, what happens post-launch, and what their failure stories are. A company that answers these with specifics and honesty — including admitting limitations — is a stronger signal than one with a flawless-sounding pitch and no portfolio detail to back it up.
How to Use This List
Don’t treat this as a rigid script to read off a page. Use it as a conversation guide across your first two or three calls with any vendor you’re seriously considering. Pay less attention to what they answer and more attention to how — specific and grounded, or vague and salesy.
A good vendor will often ask you questions back. That’s a positive sign, not a delay tactic. A vendor who agrees to everything immediately, with no clarifying questions, is often telling you they haven’t actually thought it through — or they will, after you’ve signed.
Section 1: Discovery and Scope
1. How do you handle discovery before giving me a fixed quote?
Why it matters: A real discovery process — even a short one — is where a company figures out what you actually need versus what you think you need. If a vendor gives you a detailed, fixed-price quote within a single call based on a one-paragraph description, they’re either extremely experienced in exactly your use case, or they’re guessing and will make up the difference later through change orders.
What a strong answer sounds like: “We usually spend one to two weeks on discovery for a project this size — understanding your workflows, clarifying what ‘done’ means for the first release, and identifying technical risks before we commit to a number.”
Red flag: An exact price quoted in the first conversation with no questions asked about your actual users, workflows, or constraints.
2. What happens when the scope changes mid-project? (Because it usually does.)
Why it matters: Scope almost always shifts once real users or stakeholders see working software. The question isn’t whether this will happen — it’s whether the vendor has a sane, pre-agreed process for it.
What a strong answer sounds like: “We work in short cycles, review priorities with you regularly, and if something genuinely new comes up, we’ll show you the impact on timeline and cost before building it — not after.”
Red flag: “We won’t need to change scope, we’ll get it right the first time.” No serious vendor believes this about real software projects.
3. Can you show me how you break a project like mine into phases or milestones?
Why it matters: This reveals whether they think in terms of real deliverables and checkpoints, or just a single big delivery date with nothing to review along the way.
What a strong answer sounds like: A rough phase breakdown specific to your project, with a logical first milestone that delivers something testable — not just “design phase, then development phase, then testing phase” as a generic template.
Section 2: Technical Ownership and Risk
4. Who owns the code, documentation, and infrastructure access once the project ends?
Why it matters: This is one of the most overlooked questions, and one of the most expensive to get wrong. Some contracts are written so the vendor retains certain rights, reusable components, or exclusive access to deployment accounts. You want full ownership of your own product, in writing.
What a strong answer sounds like: A clear statement that you own all code, assets, and documentation upon final payment, along with admin access to hosting, repositories, and third-party accounts — not just a vendor’s internal copy.
Red flag: Vagueness, or any answer that implies your access depends on an ongoing relationship with them.
5. What does your documentation process look like?
Why it matters: Undocumented software is a liability the moment the original developer leaves — yours or theirs. Good documentation isn’t a “nice to have,” it’s what prevents a six-month delay the next time someone needs to touch the system.
What a strong answer sounds like: Specifics — technical architecture notes, setup instructions, API documentation, and a handover document at project completion, not “we’ll write some comments in the code.”
6. How do you approach security for a project like this?
Why it matters: Even if your product isn’t handling obviously sensitive data, basic security hygiene (access control, dependency updates, secrets management) matters. A vendor who can’t describe their baseline security practices in plain language likely doesn’t have a consistent one.
What a strong answer sounds like: Specific practices — how they manage credentials, how they handle access control, whether they do any security review before launch — explained without excessive jargon.
Red flag: “Don’t worry, we take security very seriously” with no specifics when pressed.
Section 3: Team and Delivery
7. Who exactly will be working on my project, and what happens if someone leaves mid-project?
Why it matters: Sales calls are often led by senior, experienced people. The actual work may be done by a different team — sometimes a much more junior one. You want to know who’s really building your product and what the contingency plan is if a key person leaves.
What a strong answer sounds like: Specific roles assigned to your project with brief backgrounds, and a clear answer about knowledge transfer and replacement process if someone leaves.
Red flag: “We’ll figure out the team once we start” with no clarity on seniority or continuity planning.
8. What’s your quality assurance process, specifically?
Why it matters: “We test everything” tells you nothing. You want to know whether there’s a dedicated QA function, what gets tested before each release, and whether critical paths (checkout, login, payment, data integrity) get special attention versus everything being treated equally.
What a strong answer sounds like: A description of manual and/or automated testing, what’s prioritized, and how defects are tracked and resolved before release — not just “our developers test their own code.”
9. How will we communicate, and how often?
Why it matters: Mismatched communication expectations are one of the most common reasons projects feel like they’re “going badly” even when the work itself is fine. You need to know the actual cadence — not just “we’re very communicative.”
What a strong answer sounds like: A specific structure — weekly syncs, async daily updates, a shared project board you can view anytime, and a named point of contact.
Red flag: No clear answer, or an answer that implies you’ll mostly hear from them when something is already a problem.
Section 4: Commercial and Long-Term Fit
10. How do you price change requests or work outside the original scope?
Why it matters: Every project has some scope drift. What matters is whether the pricing model for that drift is transparent and pre-agreed, or whether it becomes a point of friction and surprise invoices later.
What a strong answer sounds like: A clear process — how changes are estimated, approved, and billed — ideally with a written change-request procedure in the contract.
11. Can you walk me through a project that didn’t go as planned, and what you did about it?
Why it matters: This is, in my experience, the single most revealing question on this list. Every experienced vendor has had a project go sideways — missed estimate, scope misunderstanding, a technical decision that didn’t pan out. The ones worth trusting can talk about it honestly and explain what they changed afterward.
What a strong answer sounds like: A specific, honest story with a real complication and what they learned or changed as a result.
Red flag: “We’ve never really had a project go wrong” — this usually means either very limited experience, or an unwillingness to be honest with you before you’ve even signed.
12. What does ongoing support or maintenance look like after launch?
Why it matters: Launch day isn’t the finish line. You need to know whether post-launch support is included, what response times look like for urgent issues, and what the pricing structure is for ongoing work.
What a strong answer sounds like: Specific support tiers or a described process for bug fixes versus new feature requests, with realistic response time expectations — not “we’ll always be available.”
13. How do you handle a disagreement about whether delivered work meets the agreed requirements?
Why it matters: This question tests whether there’s a defined process for resolving disputes about “done,” or whether it’s handled ad hoc and based on whoever argues harder.
What a strong answer sounds like: Reference to clear, written acceptance criteria agreed upon before work starts, with a defined review and revision process.
14. Can I speak to a past client — ideally one where things got difficult at some point?
Why it matters: Reference calls with happy clients are easy to arrange. A vendor willing to connect you with a client who had a rough patch (and how it was resolved) tells you much more about how they actually handle pressure.
What to listen for on the reference call: Not just “they were great,” but specifics about communication during a hard moment, how issues were escalated, and whether promises were kept.
15. What would make this project fail, in your honest opinion?
Why it matters: This is my favorite question to end on, because it forces genuine risk-thinking instead of a sales pitch. A good vendor will have real, specific answers — unclear requirements, unrealistic timeline pressure, lack of a decision-maker on your side, too many stakeholders with conflicting priorities.
What a strong answer sounds like: Specific, sometimes slightly uncomfortable honesty about risks — including risks on your side of the relationship, not just theirs.
Red flag: “I don’t see any real risks with this project” — nobody who has delivered real software believes this.
The Pattern That Actually Matters
If you ask all 15 of these questions, you’ll notice something: the strongest vendors answer with specifics, examples, and occasional admissions of limitation or past difficulty. The weakest vendors answer everything smoothly, confidently, and with almost no specific detail — because specificity is where overpromising gets exposed.
I’d rather work with (or recommend) a vendor who says “that’s a real risk, here’s how we’d manage it” than one who tells me there’s nothing to worry about. In 20+ years around software delivery, the second type is the one that causes problems six weeks in.
A Simple Way to Score Your Conversations
| Signal | Stronger Vendor | Weaker Vendor |
| Discovery | Asks clarifying questions, takes time before quoting | Quotes immediately with no questions |
| Scope changes | Has a defined, transparent process | Claims scope won’t change |
| Past failures | Shares a real story and what they learned | Claims they’ve never had issues |
| Ownership | Clear, written, full ownership to you | Vague or conditional on ongoing relationship |
| Team | Specific people, continuity plan | “We’ll sort the team out later” |
Common Mistakes Businesses Make During This Process
Choosing based on the lowest quote without comparing assumptions. A dramatically lower price almost always means something is excluded — QA depth, documentation, post-launch support, or seniority of the team.
Being impressed by confidence instead of specificity. Confident, vague answers feel reassuring in the moment but reveal nothing. Specific answers — even imperfect ones — are more trustworthy.
Skipping the reference call, or only asking for happy references. The real value is in asking a past client how the vendor handled something going wrong, not whether they liked them overall.
Not clarifying IP and access ownership before signing. This is the question most commonly overlooked, and the most expensive one to get wrong after the fact.
Treating the sales call and the project team as the same people. Always confirm who you’ll actually be working with day-to-day, not just who’s pitching you.
Frequently Asked Questions
1. How many vendors should I talk to before deciding?
There’s no fixed number, but two or three serious conversations are usually enough to start noticing real differences in how companies answer these questions versus how they sound in marketing material.
2. Is a lower price always a red flag?
Not always — but it should always prompt a direct question: what’s excluded compared to the higher quotes? Differences usually come down to QA depth, documentation, team seniority, or post-launch support.
3. Should I sign with a vendor who admits they’ve had failed projects?
In most cases, yes — assuming they can explain what they learned and changed. A vendor claiming a perfect track record is either inexperienced or not being fully honest with you.
4. What’s the most commonly overlooked question on this list?
Code and IP ownership after project completion. It rarely matters until you need it — and by then, it’s expensive to fix.
5. How important is industry experience compared to these questions?
Useful, but secondary. A vendor with strong process, communication, and ownership answers can often outperform one with industry experience but weak delivery discipline.
6. Should I ask for all of this in writing, or is a verbal answer enough?
Key commitments — ownership, scope-change process, support terms — should be documented in the contract or statement of work, not just discussed verbally.
7. What if a vendor answers most of these well but struggles with one or two?
That’s normal and often more trustworthy than a vendor who claims to have a perfect answer for everything. Focus on whether the struggles are in areas critical to your project.
Next Step
If you’re currently evaluating vendors and want a second opinion on their answers — or want to see how UGS Technology would answer these same 15 questions — that conversation is worth having before you sign anything. A good partner won’t mind being asked hard questions; it’s usually the clearest sign of how they’ll handle the harder moments later in the project.
