Why These 25 Questions Matter Before You Sign
Choosing the right software development partner is one of the most consequential decisions your organization will make. A bad choice can mean missed deadlines, budget overruns, security vulnerabilities, and a product that doesn't meet user needs. A great choice can transform your operations, delight your customers, and give you a competitive edge for years to come.
Yet too many procurement teams focus exclusively on price and timeline, missing critical questions about technical capability, process maturity, and long-term support. By the time red flags become obvious, you're already locked into a contract with exit costs that feel prohibitive.
This comprehensive guide gives you 25 essential questions organized into five categories. Use these during vendor interviews, RFP evaluations, and final negotiations to separate truly qualified development partners from those who simply sound good in sales meetings.
"We thought we did thorough due diligence, but we never asked about their HIPAA experience beyond 'Have you done healthcare before?' Six months in, we discovered their architecture choices made compliance nearly impossible without a complete rebuild."
— Sarah Chen, VP of Technology, Regional Health Network
Technical Expertise: Understanding Their Engineering Capabilities
Technical competence is foundational. Your vendor needs the right skills, but more importantly, they need sound judgment about architecture, security, and quality assurance. These five questions reveal whether they have both.
1. How do you decide which technology stack to recommend for a project like ours?
Why it matters: This question reveals their decision-making process and whether they default to whatever's trendy versus choosing technologies that align with your business requirements, team capabilities, and long-term maintenance needs.
What a good answer looks like: They should ask clarifying questions about your existing infrastructure, internal team skills, scalability requirements, and budget constraints. They should mention trade-offs between different approaches and explain why certain technologies might be better fits than others. Red flag: "We use [framework X] for everything" without considering your specific context.
2. Walk me through your approach to application security and data protection.
Why it matters: Security can't be bolted on after development. You need a partner who thinks about threat modeling, secure coding practices, and data protection from day one.
What a good answer looks like: They should mention specific practices like security code reviews, dependency scanning, penetration testing, encryption at rest and in transit, principle of least privilege, and security testing in their CI/CD pipeline. For healthcare and education clients, they should immediately reference HIPAA or FERPA requirements. Bonus points if they mention their own security certifications or SOC 2 compliance.
3. What does your testing and QA process look like?
Why it matters: Testing maturity directly correlates with product quality and long-term maintenance costs. Inadequate testing means you'll spend years fighting bugs instead of building features.
What a good answer looks like: They should describe a multi-layered approach including unit tests, integration tests, and end-to-end testing. They should explain their test coverage goals, automated testing infrastructure, and how QA integrates with their development workflow. They should mention both functional testing and performance/load testing. Red flag: "We test everything manually before deployment."
4. How do you handle DevOps, deployments, and infrastructure management?
Why it matters: Modern software requires sophisticated deployment pipelines, infrastructure automation, and monitoring. You need to know if they can deliver production-ready systems, not just code that "works on their laptop."
What a good answer looks like: They should discuss CI/CD pipelines, infrastructure as code (Terraform, CloudFormation, etc.), containerization strategies, automated rollbacks, monitoring and alerting systems, and their approach to zero-downtime deployments. They should explain who owns production infrastructure and how they handle scaling and performance optimization.
5. How do you ensure code quality and maintainability?
Why it matters: You're not just buying software for launch day—you're investing in a codebase you'll maintain for years. Poor code quality creates technical debt that compounds exponentially over time.
What a good answer looks like: They should mention code review processes, linting and formatting standards, architectural documentation, naming conventions, and strategies for keeping dependencies up to date. They should explain how they balance velocity with quality and how they handle refactoring. Ask to see examples of their code or documentation from past projects.
Process & Communication: How They'll Actually Work With Your Team
Technical skills matter, but so does collaboration. These questions reveal how they structure projects, communicate progress, and handle the inevitable challenges that arise during development.
6. What project management methodology do you use, and why?
Why it matters: Different methodologies suit different project types and organizational cultures. You need alignment on how decisions get made, how scope changes are handled, and how progress is measured.
What a good answer looks like: They should explain their default approach (Agile, Scrum, Kanban, hybrid) but also show flexibility based on your needs. They should describe sprint planning, retrospectives, backlog grooming, and how they prioritize features. Most importantly, they should explain how you'll be involved in the process and where you have decision-making authority.
7. How often will we receive progress updates, and in what format?
Why it matters: Transparency prevents surprises. You need regular visibility into progress, blockers, and risks—especially when you're accountable to stakeholders who aren't involved in day-to-day development.
What a good answer looks like: They should commit to specific cadences: daily standups, weekly sprint reviews, monthly executive summaries, etc. They should explain what tools they use for project tracking (Jira, Linear, Asana) and how you'll access them. Ask if you'll have read-only access to their project management tools or if updates come via email/reports only.
8. What's your escalation process when problems arise?
Why it matters: Every project encounters obstacles. What separates great vendors from mediocre ones is how quickly they surface issues and how effectively they resolve them.
What a good answer looks like: They should outline a clear chain of communication: who your primary contact is, who manages escalations, and how quickly you can expect responses for different severity levels. They should explain how they handle scope changes, timeline risks, and budget concerns. Red flag: "We've never had a project with serious issues" (unrealistic and defensive).
9. Who will be on our project team, and what's their experience level?
Why it matters: You need to know if you're getting the senior architects who impressed you in sales meetings or if your project will be staffed with junior developers learning on your dime.
What a good answer looks like: They should provide names or profiles of your proposed team, including their roles, experience levels, and relevant past projects. They should commit to minimal team turnover and explain their backup plan if a key team member leaves. Ask about their staff augmentation practices: do they subcontract work or keep everything in-house?
10. How do you handle timezone differences and working hours overlap?
Why it matters: If your vendor is offshore or distributed, timezone misalignment can slow decision-making, delay issue resolution, and frustrate your internal stakeholders.
What a good answer looks like: They should specify their core working hours in your timezone, guaranteed overlap periods for real-time collaboration, response time commitments for asynchronous communication, and how they staff projects to ensure coverage. They should acknowledge the challenges of distributed work and explain their mitigation strategies.
"The vendor we almost chose had a beautiful proposal and competitive pricing, but when we asked about their testing process, they admitted they don't write automated tests. That was a dealbreaker. We're building a financial platform—manual testing isn't good enough."
— Marcus Williams, CTO, Fintech Startup
Domain Knowledge: Proving They Understand Your Industry
General software development skills aren't enough. Your vendor needs deep familiarity with your industry's unique challenges, regulations, and user expectations.
11. What similar projects have you completed in our industry?
Why it matters: Industry experience means they understand your users' workflows, common feature requirements, integration needs, and compliance obligations without you having to educate them.
What a good answer looks like: They should provide 2-3 detailed case studies with similar scope, technology, and industry context. They should explain outcomes, not just deliverables: user adoption rates, performance improvements, cost savings, etc. Ask if they can connect you with references from these projects. If they lack direct industry experience, they should articulate how they'll get up to speed and what domain experts they'll consult.
12. How familiar are you with [HIPAA/FERPA/SOC 2/ISO 27001] compliance requirements?
Why it matters: Regulatory compliance isn't optional, and retrofitting it into a non-compliant architecture is expensive and time-consuming. Your vendor needs to build compliance in from the start.
What a good answer looks like: For healthcare projects, they should demonstrate specific HIPAA knowledge: BAA requirements, PHI handling, encryption standards, audit logging, access controls. For education, they should understand FERPA's student data protections. They should explain how compliance requirements will influence architecture decisions, vendor selection (for subprocessors), and testing procedures. Ask if they have in-house compliance expertise or if they partner with auditors.
13. What industry-specific challenges do you anticipate for a project like ours?
Why it matters: This question tests whether they've thought critically about your domain beyond surface-level research. Great vendors will surface risks and challenges you haven't considered.
What a good answer looks like: They should identify 3-5 specific challenges relevant to your industry: integration with legacy systems, complex approval workflows, data migration risks, user adoption hurdles, or regulatory constraints. They should propose mitigation strategies for each. This demonstrates both domain knowledge and strategic thinking.
14. Can you provide references from similar projects we can contact?
Why it matters: References let you validate claims, understand how they handle adversity, and learn what it's really like to work with them after the sales process ends.
What a good answer looks like: They should provide at least 2-3 references without hesitation, preferably from projects with similar scope and industry. They should give you enough context to ask informed questions. Be wary if they claim all past clients signed NDAs preventing references—that's occasionally true but often a dodge. Ask if you can speak with project managers, technical leads, or end users, not just executives.
15. How do you stay current with industry trends and emerging regulations?
Why it matters: Technology and compliance landscapes evolve rapidly. Your vendor needs to proactively track changes that affect your product.
What a good answer looks like: They should mention specific industry conferences they attend, regulatory updates they monitor, professional networks they participate in, and continuing education programs for their team. For healthcare vendors, they should reference HHS guidance updates. For EdTech, they should follow Department of Education policy changes. This shows long-term commitment to your industry, not just opportunistic project pursuit.
Commercial Terms: Protecting Your Investment
Contract terms determine what happens when things go wrong, who owns what you've built, and how much flexibility you have as requirements evolve. Don't negotiate these after you've mentally committed to a vendor.
16. What's your pricing model, and what exactly does it include?
Why it matters: "Transparent pricing" means different things to different vendors. You need clarity on what's included in the base price versus what costs extra.
What a good answer looks like: They should clearly explain whether they charge fixed-price, time-and-materials, or value-based fees. They should itemize what's included: design, development, testing, deployment, project management, etc. They should specify what's not included: third-party licenses, infrastructure costs, ongoing maintenance, training, etc. Ask about billing frequency and payment terms. For more context on typical costs, see our custom software development cost guide.
17. Who owns the intellectual property rights to the code and designs?
Why it matters: You don't want to discover months after launch that you don't fully own the software you paid to build, or that your vendor can reuse your proprietary logic for competitors.
What a good answer looks like: They should commit to full IP transfer upon final payment, ideally with clear language in the contract stating you own all custom work product. They may retain rights to pre-existing frameworks or libraries they bring to the project—that's reasonable. But anything built specifically for you should be yours. Ask about trademarks, domain names, and design assets too.
18. What's your payment schedule, and what happens if we need to pause or cancel?
Why it matters: Payment schedules affect your cash flow and risk exposure. You need to understand what you're committing to financially and what flexibility you have if business circumstances change.
What a good answer looks like: Common structures include: deposit at contract signing (20-30%), milestone-based payments, or monthly billing for time-and-materials. They should explain what triggers each payment, what deliverables you'll receive, and your review/approval rights. For cancellation, they should specify notice requirements, what you'll own up to that point, and any cancellation fees. Avoid contracts requiring 100% upfront payment.
19. How do you handle scope changes and change requests?
Why it matters: Requirements evolve during development—that's normal. But you need a fair, predictable process for evaluating and pricing changes, or you'll face constant battles over what was "in scope."
What a good answer looks like: They should describe a change request process: how changes are proposed, how they're evaluated for technical impact, how they're priced, and what approval is required. They should distinguish between minor clarifications (usually free) versus major feature additions (usually billable). They should commit to written change orders before doing work that affects timeline or budget. Ask about their buffer for minor scope adjustments.
20. What warranties or service-level agreements do you provide?
Why it matters: You need recourse if the delivered software doesn't work as specified or if critical bugs emerge shortly after launch.
What a good answer looks like: They should offer a warranty period (typically 30-90 days) during which they'll fix bugs at no charge. They should define what constitutes a "bug" versus a "feature request." For mission-critical systems, they may offer SLAs around uptime, response times, and resolution times—especially if you're purchasing a support retainer. Get these commitments in writing.
Post-Launch Support: Planning for Life After Launch
Launch day is the beginning, not the end. Your vendor's post-launch support determines whether your software remains secure, performs well, and adapts to changing needs.
21. What ongoing maintenance and support plans do you offer?
Why it matters: Software requires ongoing security patches, dependency updates, bug fixes, and minor enhancements. You need to know if they'll support you long-term or if you'll need to find a new vendor immediately after launch.
What a good answer looks like: They should offer tiered support plans with clear service levels: response times, included hours, escalation procedures, and pricing. They should explain what's covered under maintenance (security updates, bug fixes, performance optimization) versus what requires additional development work (new features). Ask about minimum contract terms and rate locks.
22. What's your SLA for critical bug fixes after launch?
Why it matters: When your production system goes down or a critical bug affects users, you need to know how quickly your vendor will respond and resolve the issue.
What a good answer looks like: They should define severity levels (critical, high, medium, low) with specific response and resolution timeframes for each. For example: critical bugs acknowledged within 1 hour and resolved within 4 hours. They should explain their on-call coverage and after-hours support availability. Ask what happens if they miss an SLA—do you get service credits or other remedies?
23. How will you transfer knowledge to our internal team?
Why it matters: Eventually, your internal team will need to understand the system's architecture, make minor updates, or troubleshoot issues without vendor involvement. Poor knowledge transfer leaves you permanently dependent on your vendor.
What a good answer looks like: They should include documentation deliverables: architecture diagrams, API documentation, deployment runbooks, code comments, and user guides. They should offer training sessions for your technical team and administrators. Ask if documentation is included in the project price or if it costs extra. Request samples of documentation from past projects.
24. What documentation will you provide, and in what format?
Why it matters: Documentation quality varies wildly. You need comprehensive, maintainable documentation that your team can actually use, not auto-generated API docs with no context.
What a good answer looks like: They should commit to multiple documentation types: technical architecture documentation, API/integration documentation, admin user guides, end-user documentation, and operations/deployment guides. Ask about documentation tools, formats (Markdown, Confluence, etc.), and how they keep docs updated during development. Poor documentation is a major reason why choosing the right development partner matters so much.
25. How do you handle scaling support as our user base grows?
Why it matters: Your software needs to grow with your business. You need a vendor who can help you scale infrastructure, optimize performance, and add capacity without complete rewrites.
What a good answer looks like: They should ask about your growth projections and explain how the architecture will accommodate scaling. They should discuss horizontal vs. vertical scaling strategies, caching layers, database optimization, and cloud infrastructure elasticity. They should offer ongoing performance monitoring and optimization as part of their support plans. Ask if they've helped other clients successfully scale from initial launch to 10x or 100x traffic.
"We created a scorecard with weighted criteria for each vendor response to these questions. It made what felt like a subjective decision much more objective and defensible to our executive team. The vendor we chose wasn't the cheapest, but they scored highest on technical expertise and domain knowledge—the factors that mattered most."
— Jennifer Park, Director of Digital Strategy, Manufacturing Company
How to Use These Questions During Vendor Selection
Having these 25 questions is valuable, but knowing how to use them effectively is crucial. Here's a practical approach for your vendor evaluation process:
1. Send questions in advance. Include these questions in your RFP or send them before discovery calls. This gives vendors time to prepare thoughtful responses and signals that you're conducting serious due diligence.
2. Create a scoring rubric. Assign weights to categories based on your priorities. Healthcare organizations might weight domain knowledge and security highest. Startups might prioritize technical expertise and agile process. Score each vendor consistently.
3. Ask follow-up questions. Generic answers deserve probing. If they say "we follow Agile," ask about their specific sprint length, retrospective format, and how they handle mid-sprint scope changes.
4. Request evidence. Don't accept claims at face value. Ask for code samples, documentation examples, reference calls, and case studies. Watch out for common red flags during this process.
5. Involve technical stakeholders. Your procurement team can evaluate process and commercial terms, but you need technical leadership to assess architecture approaches, code quality, and DevOps maturity.
6. Document everything. Record responses, score each vendor, and maintain an audit trail of your decision-making process. This protects you if stakeholders later question your choice.
Red Flags to Watch For During Vendor Interviews
As you ask these questions, watch for these warning signs that suggest a vendor may not be the right partner:
- Vague or evasive answers: If they can't explain their testing process or security practices clearly, they probably don't have robust ones
- Overpromising: "We've never missed a deadline" or "We can build anything" suggests inexperience or dishonesty
- Pressure tactics: "This price is only good until Friday" or "Another client is interested in this team" are sales manipulation techniques
- No references: Legitimate vendors are proud to connect you with satisfied clients
- Cookie-cutter proposals: Generic proposals that don't address your specific industry, compliance needs, or technical challenges
- Resistance to contracts: Avoiding specific SLAs, warranties, or IP terms in writing
- Team uncertainty: Can't or won't commit to specific team members for your project
What Happens After You Ask These Questions
The vendors who provide thoughtful, detailed answers to these 25 questions are demonstrating several important qualities:
Transparency. They're willing to explain how they work rather than hiding behind sales-speak.
Experience. They've thought through these issues before because they've encountered them on past projects.
Confidence. They know their processes work and aren't afraid to be evaluated on them.
Alignment. They understand that successful partnerships require shared expectations and clear communication.
The vendors who provide evasive, generic, or defensive answers are revealing that they either lack the maturity to be a reliable partner or aren't the right fit for your project's specific needs.
Get Answers to All 25 Questions—and More
At Of Ash and Fire, we welcome these questions because we've built our entire practice around the principles they represent: technical excellence, clear communication, domain expertise, fair commercial terms, and long-term partnership.
We specialize in custom software development for healthcare, education, and manufacturing organizations that need HIPAA-compliant systems, scalable learning platforms, and industrial automation solutions. We've answered these questions hundreds of times for clients ranging from regional health networks to national EdTech companies to advanced manufacturers.
If you're evaluating development partners for an upcoming project, we'd like to be part of that conversation. We'll answer all 25 of these questions—and any others you have—in a free, no-pressure consultation call. We'll also provide:
- A preliminary technical assessment of your project requirements
- Case studies from similar projects in your industry
- A transparent explanation of how we'd approach your specific challenges
- References you can contact to hear about real client experiences
Whether you ultimately choose us or another vendor, you'll leave the conversation with a better understanding of what to look for in a development partner and what questions matter most for your specific project.
Schedule your free consultation or explore our development packages to see how we've structured our services around the needs of clients like you.
Because the right vendor doesn't just answer your questions—they help you ask better ones.