Choosing a software development company is one of those decisions where the cost of getting it wrong is far higher than the cost of the project. A bad partner doesn't just waste the budget. It costs months, leaves you with code that another firm has to untangle, and often sours the whole organization on the idea of custom software.
The good news is that bad partners are usually detectable early. They tend to fail the same questions, and they tend to show the same warning signs in the first conversation. This guide gives you those questions, organized by what they reveal, along with what a good answer sounds like.
We're a development firm, so we have a stake in this. We've tried to make the questions ones that we'd want to be asked, and ones that would filter out competitors we'd rather you not hire.
Red flags in the first conversation
Before getting to the questions, a few things that should make you cautious immediately:
- They give you a confident price before understanding the project. A firm that quotes a complex build in the first call is guessing. Later, either the price goes up or the quality goes down.
- They say yes to everything. No timeline is too tight, no feature is a problem, no requirement raises a concern. Real engineering involves tradeoffs, and a partner who never mentions them either doesn't understand them or doesn't plan to tell you.
- They can't explain who will actually do the work. Sales conversations with senior people, then a project delivered by a team you never met, is a common pattern.
- They push a specific technology before understanding the problem. "We'll build it in [framework]" before "What are you trying to accomplish?" means they're selling what they have, not solving what you need.
- Everything is about them. Portfolio, awards, team size. Not questions about your business, your users, or your constraints.
None of these is disqualifying alone. Together, they're a pattern.
The 12 questions
Process and approach
1. What does your discovery process look like, and what do we get at the end of it?
Discovery is the phase where a firm learns your business, defines the scope, and designs the approach before writing production code. Its absence is the single most reliable predictor of a troubled project.
A good answer: A structured phase (usually two to four weeks for a mid-size project) involving stakeholder interviews, workflow mapping, and technical assessment, producing a written scope, a proposed architecture, a phased plan, and a much tighter estimate. Discovery is typically paid separately, and you should be free to take the deliverables elsewhere if you choose.
A bad answer: "We'll figure it out as we go," or a discovery phase that's just a sales meeting with a different name.
2. How do you handle changes in scope mid-project?
Requirements change. That's normal. What matters is whether the firm has a process for it or whether every change becomes an argument.
A good answer: A defined change process: the change is documented, its impact on timeline and cost is estimated, you approve or decline, and the plan is updated. Small changes are often absorbed; larger ones are priced. Everyone knows the rules in advance.
A bad answer: "We're flexible" without specifics, which usually means the flexibility runs in one direction.
3. How do you test, and what's your definition of done?
The difference between software that works in a demo and software that works in production is testing.
A good answer: Automated tests written alongside the code, a staging environment that mirrors production, a defined QA process before release, and "done" meaning tested, reviewed, documented, and deployable, not just "the feature exists."
A bad answer: "We test thoroughly" with no details, or testing described as something that happens at the end.
Team
4. Who exactly will be working on our project, and what are their roles?
A good answer: Names, roles, and seniority of the actual team. Clarity on who leads technically, who manages the project, and who your day-to-day contact is. If the firm uses contractors or offshore team members, they say so plainly.
A bad answer: Vague references to "our team" or resistance to introducing you to the people who'll be doing the work.
5. How much of the work is done by senior engineers versus junior ones?
A team of juniors supervised by one stretched senior is cheap per hour and expensive per outcome. You're not paying for hours; you're paying for the product.
A good answer: An honest ratio, and an explanation of how senior people are involved in architecture decisions, code review, and the hard problems, even if more routine work is done by mid-level engineers.
6. Have you built something similar before, and can we talk to that client?
Relevant experience matters less than people assume (good engineers move between domains well), but it does reduce risk, and a client reference tells you more than any portfolio page.
A good answer: Specific examples with real detail, and a willingness to connect you with a past client. Also honesty when something is new to them; that honesty is a good sign.
A bad answer: A portfolio full of logos but no willingness to make an introduction.
Communication and visibility
7. How will we know what's happening week to week?
Software projects go wrong quietly. By the time a problem is visible in a demo, it's usually been a problem for weeks.
A good answer: A regular rhythm: weekly (or more frequent) check-ins, a shared board where you can see progress, working software demonstrated at regular intervals rather than a single reveal at the end, and a direct line to the team for questions.
A bad answer: Monthly status reports and a promise to "let you know if anything comes up."
8. What happens when something goes wrong?
Something will. A dependency will break, an estimate will be wrong, a key engineer will get sick. The question is how the firm behaves.
A good answer: They tell you early, they come with options, and they take responsibility for their part. Ask for an example of a project that hit problems and how they handled it. The story tells you a lot.
A bad answer: "That doesn't really happen to us."
Ownership and technical foundation
9. Who owns the code, and when?
This is a contract question, and it's non-negotiable.
A good answer: You own all intellectual property in the custom work, assigned to you upon payment, with the code delivered to a repository you control. The firm may retain rights to general-purpose tools or libraries it brings to the project, and that should be spelled out.
A bad answer: Any arrangement where the firm retains ownership, licenses the code back to you, or requires ongoing payment to keep using what you paid to build.
10. Could another team take over this codebase if they had to?
You may never leave. But you should be able to. This question tests whether the firm builds in a way that's maintainable by others or in a way that makes you dependent on them.
A good answer: Standard, widely used technologies chosen for fit rather than novelty, documentation, readable code with reasonable test coverage, infrastructure defined in code, and a clear handover process. A confident firm welcomes this question.
A bad answer: Proprietary frameworks, undocumented systems, or a subtle implication that switching would be painful.
11. What technology will you use and why?
You don't need to evaluate the technical answer. You need to evaluate whether there's a reason behind it.
A good answer: Choices explained in terms of your needs: scale, team availability, longevity, integration with your existing systems. A willingness to work within your existing stack if you have one.
A bad answer: One technology for every project regardless of fit, or the newest thing because it's new.
After launch
12. What happens after the project ships?
Launch is the beginning of the software's life, not the end of the project.
A good answer: A defined warranty period for defects, clear options for ongoing maintenance (retainer, hourly, or a support agreement), monitoring so problems are caught before users report them, and a willingness to train your internal team if you want to bring maintenance in-house.
A bad answer: Silence on the topic, or support that's only available as an expensive afterthought.
How to read a proposal
Once you've had conversations with a few firms, the proposals arrive. Here's what to look at beyond the price:
Is the scope specific? A proposal should describe what's being built in enough detail that you could identify something missing. Vague scope is the root of most disputes.
What's excluded? Good proposals state exclusions explicitly: design, content, data migration, third-party service costs, app store submissions, post-launch support. If nothing is excluded, ask.
Is the estimate a range or a point, and why? For anything beyond a small project, an honest estimate is a range with an explanation of what drives the variance. A precise fixed price on an uncertain project means either padding or future change orders.
What are the assumptions? Every estimate rests on assumptions: that your API documentation is accurate, that you'll provide feedback within a certain time, that the existing database is in reasonable shape. These should be written down.
Does the timeline include your time? Projects depend on client decisions, feedback, and content. If the timeline assumes instant responses from your side, it's optimistic.
Compare apples to apples. If quotes differ by 3x for what sounds like the same project, they aren't for the same project. Go back to both firms and ask what accounts for the difference. The answer is usually illuminating.
What a good discovery phase looks like
Since discovery comes up in so many of these questions, here's what you should expect from one done well:
- Stakeholder interviews. The firm talks to the people who will use the software, the people who will pay for it, and the people who maintain the systems it touches. Not just the executive sponsor.
- Workflow mapping. Current processes documented as they actually happen, including the workarounds, not as they're described in the org chart.
- Technical assessment. Existing systems, data, integrations, and constraints evaluated hands-on, not from a slide deck.
- Prioritized scope. Features organized into what's essential for the first release and what comes later, with your input.
- Architecture and approach. How the system will be built, what technology, why, and how it fits with what you have.
- Phased plan and estimate. A sequence of releases, each with its own estimate, so you can make decisions phase by phase.
- Risks. What could go wrong and how it will be managed. A discovery document with no risks section is incomplete.
You should come out of discovery understanding your own project better than you did going in. If you don't, something went wrong.
Frequently asked questions
Should I choose the cheapest quote?
Is a local firm better than a remote one?
How many firms should I talk to?
What if we're not sure custom software is the right choice?
How much should I budget?
Choosing well
The best software development partnerships have a few things in common: honest scoping, the right people actually doing the work, visibility throughout, clear ownership, and a plan for what comes after launch. The twelve questions above are designed to surface all of those in the first few conversations.
If you'd like to put these questions to us, we'd welcome it. Schedule a call and we'll walk you through how we work, introduce you to the people who'd be on your project, and give you a straight answer about whether we're the right fit.