Most buyers ask the wrong first question: “What’s your hourly rate?” Rate matters—but the difference between a successful build and a slow-motion disaster almost always comes down to how the team works, not their sticker price.
The questions below are grouped so you can run a structured conversation with any software development company, local or offshore. Use them alongside our pricing guide and RFP template.
Quick Answer: The 5 Themes You Must Cover
- Fit: Have they built anything like what you want before?
- Architecture & quality: How do they design, test, and maintain systems?
- Team: Who actually works on your project—and how senior are they?
- Process & pricing: How do they estimate, communicate, and handle change?
- Ownership & risk: Who owns code, infra, and what happens when things go wrong?
1. Fit & Relevant Experience
- “Tell me about 2–3 projects most similar to what we’re planning.”
Follow‑up: industry, budget range, timeline, and live URL if possible. - “What changed between the original scope and what actually shipped?”
You’re looking for honesty about scope evolution, not a fairy tale. - “What type of work do you say no to?”
Real teams know their lane; generalists who say “everything” rarely excel at anything.
2. Architecture & Technical Depth
- “If you were designing our system, how would you break it down at a high level?”
Look for sane boundaries (modules/services), clarity about trade‑offs, and mention of observability. - “Which parts of the system are likely to be most complex or risky?”
Any answer that pretends there is no risk is itself a risk. - “Show me an architecture diagram and a README from a similar project.”
You want to see how they communicate design to non‑authors. - “How do you handle security: secrets, access control and dependency updates?”
Listen for specifics: where secrets live, who has production access, and how updates get applied.
3. Team Composition & Continuity
- “Who will be the lead engineer or architect on our project?”
Ask to meet them, not just a salesperson. - “How many projects are they actively leading right now?”
Three is normal, ten is a red flag. - “What happens if a senior engineer leaves mid‑project?”
Listen for documentation, code review discipline, and pairing—not just “we’ll replace them.”
4. Delivery Process & Communication
- “Walk me through a typical 2‑week sprint with your team.”
How do they plan, build, demo, and incorporate feedback? - “How often will we see working software?”
Good answer: every sprint. Bad answer: “Every few months when we’re ready.” - “What tools do you use for backlog, documentation, and deployment?”
Look for a coherent stack, not improvisation every time. - “How do you handle scope changes?”
Clarify change‑control, pricing impact, and how decisions are documented. - “Who will I talk to day to day, and how quickly do they reply?”
How fast they answer during the sales process is a fair preview of how fast they will answer during the build.
5. Pricing, Estimates & Models
Use this section together with the pricing breakdown and the comparison of fixed‑bid vs T&M vs dedicated teams.
- “How do you estimate projects—and how accurate are your estimates historically?”
Ask for examples where they were off and what they learned. - “Which pricing model do you recommend for our project and why?”
You’re testing for alignment with your risk tolerance, not just their cash‑flow preferences. - “What’s included in your price—and what isn’t?”
Clarify environments, monitoring, QA, project management, and post‑launch support.
As a reference point, this is what a written proposal should contain when I quote a project: the scope, the milestones, the acceptance criteria and one fixed price.
6. Ownership, Handover & Support
- “Who owns the source code, infrastructure accounts, and CI/CD pipelines?”
The answer should be: you do. - “How is knowledge captured so we’re not dependent on one or two people?”
Listen for written documentation, architecture overviews, and runbooks. - “What support and maintenance options do you offer after launch?”
Map their retainers or SLAs to your internal capacity. - “If we part ways, what does the handover include?”
Code, documentation, credentials and a walkthrough. When I handed over the SPSTARPLAST ERP, that meant a clean repository, English technical documentation and a written technical-debt report.
7. References & Proof
- “Can we speak with 2–3 clients whose projects look like ours?”
Ideally, at least one technical stakeholder. - “Which case studies best reflect what we’re trying to do?”
Review them ahead of time. Good case studies name the client and show measured results. - “What’s a project that went badly—and what did you change afterwards?”
Mature teams have scars and lessons, not just success stories.
8. Turn These Questions into a Simple Scorecard
For each vendor, score answers on a simple 1–5 scale for:
- Technical depth and clarity.
- Process maturity and communication.
- Cultural fit and transparency.
- Alignment with your budget and risk profile.
If you’re currently shortlisting partners, you can also:
- Use our RFP template as the structure for written responses.
- Anchor budget expectations with the company pricing guide.
- Compare models using the fixed‑bid vs T&M vs dedicated team breakdown.
Want a second opinion on a proposal you've already received? Send it over and I'll tell you plainly whether I think the plan will work, and which of these 25 questions it leaves unanswered.
Frequently Asked Questions
What should I ask before hiring a software development company?
Ask about their experience with similar projects, their architecture approach, security practices, delivery process, team composition, pricing model and references, and who will own the source code and infrastructure. You want to understand not just what they build but how they build and support it.
How many vendors should I interview?
For most projects, 2–4 serious vendors is right. Fewer and you risk missing a good fit; more and you're running a process nobody has time to do properly. Use a short discovery call plus a structured question list to narrow down to 1–2 finalists.
