Let me tell you about two companies that both hired development partners in the same month last year.

Company A chose based on impressive portfolios and competitive pricing. Six months and $180,000 later, they had software that technically worked but didn't solve their problem. They're now rebuilding it.

Company B asked tougher questions upfront, chose a partner who challenged their assumptions, and spent $140,000 over four months to get software that transformed their operations. ROI achieved in six months.

The difference wasn't luck—it was asking the right questions before signing the contract.

Question 1: How Do You Balance Discovery with Delivery?

This question reveals their development philosophy.

Red flag answers:

• "We spend 6-8 weeks in discovery creating comprehensive specifications before writing any code."
• "We can start coding immediately based on your requirements."

Both extremes are problematic. Months of discovery delays value and often produces specifications that don't survive contact with reality. Jumping straight to coding without understanding context creates expensive mistakes.

What you want to hear: "We do rapid discovery in 1-2 weeks through collaborative working sessions, then move to working prototypes quickly. We refine requirements iteratively as we build and learn together."

Follow-up: "Can you show me an example of how this worked on a recent project?"

Question 2: What AI Tools Do You Actually Use, and How?

Everyone claims to use AI now. Most are lying or using it superficially.

Red flag answers:

• "We're very excited about AI" (excitement isn't capability)
• "Our developers sometimes use ChatGPT" (that's individual experimentation, not systematic integration)
• "AI writes most of our code" (who's ensuring quality?)

What you want to hear: "Our developers use AI tools like Claude Code integrated directly into their workflow for code generation, testing, and optimization. AI accelerates routine implementation, allowing our senior engineers to focus on architecture and complex problem-solving. Here's how it impacts our timelines..."

They should cite specific tools and explain concretely how AI changes their development process and your timeline.

Follow-up: "How have your development timelines changed since adopting these tools?"

If they can't point to materially faster delivery, they're not leveraging AI effectively.

Question 3: When Will We See Working Software?

This reveals whether they do iterative development or waterfall.

Red flag answers:

• "You'll see the first version after 3-4 months of development"
• "We'll show you designs and prototypes early, then build from there"

What you want to hear: "You'll see a working prototype within 2-3 weeks. Not designs—actual functional software you can test. Then we'll deliver iterative improvements weekly or bi-weekly based on your feedback."

The key word is "functional." Mockups and prototypes aren't enough—you want working software fast.

Follow-up: "What exactly will that first prototype include?"

Question 4: Who Will Actually Be Building Our Software?

This is crucial and often glossed over.

Red flag answers:

• "Our team of developers will work on your project" (too vague)
• "We have developers in [low-cost region] who are excellent" (what's the supervision and quality control?)

What you want to hear: "You'll work directly with [names], who have [specific relevant experience]. They'll be hands-on writing code, making architectural decisions, and collaborating with your team. Here's their background..."

Follow-up: "Can we talk to these developers before starting?" and "What happens if key developers leave during our project?"

Question 5: What's Your Experience With Problems Like Ours?

Relevant experience dramatically accelerates development and reduces risk.

Red flag answers:

• "We've built software for all kinds of industries" (generalists often miss domain-specific nuances)
• "Every project is unique, so past experience doesn't really apply"

What you want to hear: "We've built similar solutions for [specific examples]. Here's what we learned that applies to your situation. Here are the common pitfalls we'll help you avoid..."

Follow-up: "Can we talk to any of those clients?"

Question 6: How Do You Handle Changing Requirements?

Requirements always change during development. This question reveals whether they're stuck in waterfall thinking or embrace iterative development.

Red flag answers:

• "We create detailed specifications upfront to avoid scope changes"
• "Changes after specifications are approved require change orders and timeline extensions"

What you want to hear: "We expect requirements to evolve as you see working software and learn what works. We use agile methodologies with regular prioritization—new features can be added by adjusting priorities or extending timeline, but we make those tradeoffs explicit and collaborative."

Follow-up: "Can you give me an example of a project where requirements changed significantly and how you handled it?"

Question 7: How Do You Ensure Security and Quality?

This shouldn't be an afterthought.

Red flag answers:

• "We'll do security testing before launch"
• "We follow best practices" (too vague)

What you want to hear: "Security is built in from the start—secure authentication, encryption, role-based access control, input validation, audit logging. We conduct code reviews, use automated security scanning, and do penetration testing before launch."

They should cite specific practices and tools, not just assurances.

Follow-up: "Have you ever had a security incident on software you built? How did you handle it?"

Question 8: What Happens After Launch?

Software isn't done when it launches—it needs ongoing maintenance and enhancement.

Red flag answers:

• "We deliver completed software, then hand it off to your team"
• Vague "we offer support" without specifics

What you want to hear: "We offer ongoing maintenance retainers that cover updates, bug fixes, minor enhancements, and security patches. Most clients need 5-10 hours monthly initially. For larger enhancements, we can work on sprint-based engagements."

You want clarity on post-launch support before you need it.

Question 9: How Do You Communicate Progress and Handle Problems?

Communication style matters enormously.

Red flag answers:

• "We'll send weekly status reports"
• "You can check our project management tool anytime"

What you want to hear: "We have structured weekly demos where you see working software and provide feedback. Between demos, we're available on Slack/Teams for questions. When we encounter blockers or risks, we flag them immediately rather than letting them accumulate."

You want proactive communication, not just reports you have to request.

Question 10: What Could Go Wrong With Our Project?

This reveals whether they're being honest or just selling.

Red flag answers:

• "Nothing should go wrong if we follow our process"
• Only mentioning risks on your side
• Inability to identify potential challenges

What you want to hear: "Based on what you've described, here are the areas of highest uncertainty... Here's how we'll de-risk them... Here's what could extend timeline... Here's what we don't know yet that we'll need to figure out..."

Good partners acknowledge uncertainty and explain how they'll manage it rather than pretending everything is predictable.

Question 11: Are You Order-Takers or Strategic Partners?

This reveals their level of engagement.

Red flag answers:

• "We'll build whatever you tell us to build"
• Complete agreement with everything you say

What you want to hear: "Based on what you've described, here's what we'd do differently and why... Have you considered this approach instead?... Here's what we've seen work better in similar situations..."

You want partners who challenge assumptions and suggest better approaches, not ones who blindly follow instructions.

Follow-up: "Can you give me an example of a time you talked a client out of building something they wanted?"

Questions That Reveal Cultural Fit

Beyond technical capability, ask about working style:

"What hours will you be available?" (especially important if working across time zones)

"How do you handle urgent issues outside normal business hours?"

"What's your typical client relationship duration?" (One-and-done projects or ongoing partnerships?)

"What do you wish more clients understood about software development?"

What to Do With the Answers

Don't just collect answers—compare them across partners. Look for:

Specificity over generalities: Details about actual approaches beat vague assurances

Honest acknowledgment of challenges: Partners who admit uncertainty and explain how they'll manage it are more trustworthy than those claiming everything is certain

Clear communication: If they can't explain their approach clearly now, communication during the project will be painful

Relevant experience: Specific relevance to your problem, not just "we've built a lot of software"

Modern practices: AI-powered development, iterative approaches, rapid prototyping—not 2015 waterfall methodologies

The Bottom Line

Choosing a development partner based on portfolios and price is like choosing a doctor based on their website and hourly rate.

What matters is:

• Can they deliver on timeline?
• Will they challenge you when you're wrong?
• Do they use modern approaches that accelerate development?
• Will you work with senior people who make good decisions?
• How will they handle the inevitable challenges and changes?

Ask hard questions. Push for specifics. Talk to references. If a partner gets defensive or can't provide clear answers, that's your answer—keep looking.

The difference between a great development partner and a mediocre one isn't 10% better outcomes—it's the difference between software that transforms your business and expensive disappointment.

Choose carefully.