Questions to Ask During a Software Consulting Discovery

The Questions That Reveal the Truth

A software consulting discovery session is your chance to evaluate a potential partner and determine if they're the right fit. But most people go into these meetings unprepared, asking generic questions that don't reveal anything useful.

The right questions reveal expertise, process maturity, and cultural fit. Here are the questions that matter — and what to listen for in the answers.

Questions About Their Approach

1. "Walk me through how you would approach our project."

What to listen for:

Do they start with understanding your business, or jump to technology?

Do they ask clarifying questions, or assume they understand?

Do they mention discovery, requirements, and design before development?

Red flag: They immediately start talking about technology solutions without understanding your problem.

2. "What questions do you have for us?"

What to listen for:

Are their questions thoughtful and specific to your situation?

Do they ask about business goals, not just technical requirements?

Do they ask about constraints, risks, and success criteria?

Red flag: No questions, or only generic questions that could apply to any project.

3. "How do you handle requirements that change during development?"

What to listen for:

Do they have a clear change management process?

How do they balance flexibility with scope control?

What's their approach to scope creep?

Red flag: "We'll just figure it out as we go" without a process for managing changes.

Questions About Their Experience

4. "Can you show me a similar project you've completed?"

What to listen for:

Do they have relevant experience in your industry or technology?

Can they show concrete results, not just screenshots?

Do they explain what they learned, not just what they built?

Red flag: No relevant experience, or unwillingness to share details.

5. "What was the biggest challenge on your last project, and how did you handle it?"

What to listen for:

Honesty about challenges (everyone has them)

Clear problem-solving approach

Lessons learned and how they apply to your project

Red flag: "We've never had any challenges" — that's not credible.

6. "What would you do differently if you could start that project over?"

What to listen for:

Self-awareness and continuous improvement

Specific improvements they've made to their process

How those lessons apply to your project

Red flag: No reflection or learning from past experiences.

Questions About Their Team

7. "Who would actually be working on our project?"

What to listen for:

Can they introduce you to the actual team members?

What's the team's experience level?

How stable is the team? (Low turnover is good)

Red flag: "Our team" without introducing specific people.

8. "What's your team's turnover rate?"

What to listen for:

Low turnover (under 15% annually) indicates a healthy organization

High turnover means knowledge loss and instability

How they handle team member departures

Red flag: High turnover, or inability to answer the question.

9. "How do you handle team member changes during a project?"

What to listen for:

Knowledge transfer process

How they minimize disruption

Whether you'll have input on new team members

Red flag: No process for handling team changes.

Questions About Their Process

10. "How do you communicate project status?"

What to listen for:

Regular, structured communication (daily standups, weekly reports)

Transparency about progress, risks, and issues

Tools they use for project management and reporting

Red flag: Vague answers about communication cadence or tools.

11. "How do you handle disagreements or conflicts?"

What to listen for:

Clear escalation process

Focus on resolution, not blame

How they handle technical disagreements

Red flag: No process, or "we'll figure it out."

12. "What happens if the project is behind schedule?"

What to listen for:

Root cause analysis approach

Recovery planning process

How they communicate delays

Whether they've been in this situation before and how they handled it

Red flag: "That won't happen" — projects always have surprises.

Questions About Quality

13. "How do you ensure code quality?"

What to listen for:

Code review process

Automated testing approach

Quality metrics they track

Technical debt management

Red flag: No clear quality process, or "we'll test at the end."

14. "How do you handle security?"

What to listen for:

Security practices integrated into development

Vulnerability scanning and testing

Compliance experience (if relevant)

Data handling and privacy practices

Red flag: Security is an afterthought, not a core practice.

Questions About the Business Relationship

15. "What does a successful engagement look like to you?"

What to listen for:

Do they define success in terms of your business outcomes?

Do they mention long-term partnership, not just project completion?

Do they talk about measurable results?

Red flag: Success defined as "delivering the project" rather than achieving business goals.

16. "What's your pricing model and how do you handle estimates?"

What to listen for:

Transparent pricing with clear assumptions

Range estimates, not single numbers

How they handle estimation uncertainty

What's included vs excluded

Red flag: Single-number estimates without assumptions or ranges.

17. "Can you provide references I can contact?"

What to listen for:

Willingness to provide references

Mix of current and past clients

Clients with similar project types

Red flag: Unwillingness to provide references, or only providing references from very old projects.

Questions About the Future

18. "How do you handle post-launch support?"

What to listen for:

Warranty period and what's covered

Ongoing maintenance options

How they handle bug fixes and updates

Support response times

Red flag: No post-launch support, or support treated as a separate sales process.

19. "What happens if we want to bring development in-house later?"

What to listen for:

Knowledge transfer support

Documentation practices

Code ownership and access

Transition planning

Red flag: Resistance to knowledge transfer, or unclear IP ownership.

20. "What's the biggest risk you see in our project?"

What to listen for:

Honest assessment of risks

How they would mitigate those risks

Whether they've faced similar risks before

Red flag: "I don't see any risks" — every project has risks.

After the Discovery Session

Evaluate the Conversation

Ask yourself:

Did they listen more than they talked?

Were their questions specific to our situation?

Did they demonstrate relevant expertise?

Did I feel understood and valued?

Would I enjoy working with these people?

Compare Multiple Partners

Don't decide based on one conversation. Talk to 3-5 partners and compare:

Technical expertise

Communication quality

Cultural fit

Pricing and value

Process maturity

Key Takeaways

A discovery session is your chance to evaluate a partner, not just get a pitch

Ask questions that reveal expertise, process, and cultural fit

Listen for honesty, specificity, and self-awareness

Watch for red flags: vague answers, no relevant experience, pressure tactics

Compare multiple partners before making a decision

Trust your gut — if something feels wrong, it probably is

FAQ

What questions should I ask during a software consulting discovery session?

Ask about their approach, relevant experience, team composition, communication process, quality practices, pricing model, and post-launch support. Listen for honesty, specificity, and self-awareness. Watch for red flags like vague answers or pressure tactics.

How many software development companies should I talk to before deciding?

Talk to 3-5 companies before making a decision. This gives you enough comparison points to evaluate expertise, pricing, and cultural fit. Don't decide based on a single conversation.