You already have a favorite. Somewhere in your shortlist is the team whose deck looked the sharpest, whose sales call felt the most confident, who came back with a number faster than anyone else. That's usually the moment a custom software project starts going wrong, not six months in when the timeline slips, but right now, while you're still deciding who gets your budget.
I've watched this pattern play out from both sides. As a CTO who reviews pull requests and sits in on discovery calls, I can tell within the first conversation whether a partner is going to build something that lasts or something that needs to be rebuilt in eighteen months. This isn't a checklist of generic questions to memorize. It's a way of testing whether a custom software development partner actually understands your business before they start telling you how to fix it.
Why vetting a partner is a discovery decision, not a procurement one
Most vendor-vetting advice treats this like buying software off a shelf. Compare features, compare price, pick a winner. That approach breaks down for custom software development, because the vendor isn't just delivering a product. They're deciding, in real time, what gets built and how.
The single most predictive signal of how a partner will behave after you sign is how they behave before you sign. Do they try to understand your business problem, or do they jump straight to a solution? That question matters more than their portfolio, their pricing model, or how polished their pitch deck looks. A partner who discovers before they propose is telling you something true about how they'll work once the contract is signed. A partner who proposes before they discover is telling you something true too, and it usually shows up later as scope creep, change orders, or a rebuild you didn't budget for.
This matters more for a PE-backed operator replacing an aging or outgrown SaaS stack than it does for almost anyone else evaluating custom software vendor selection. You're not choosing between two similar tools with similar switching costs. You're choosing who gets to define what "done" looks like for a system your team will depend on for years, and that's a much harder thing to walk back once work has started.
I still sit in on discovery calls for new client engagements, and the pattern holds every time. The vendors who ask three questions and start talking architecture are the ones whose projects come back to us for a rebuild a year or two later. The partners worth trusting spend that first call trying to talk you out of half of what you think you need.
What good discovery actually looks like
Good discovery isn't a formality before the real work starts. It's the clearest signal you'll get about how this partner operates, and it shows up in three specific places during the sales process.
The questions a real partner asks before proposing anything
A discovery-first partner spends the first one or two calls asking about your business, not their solution. Watch for questions like these:
What's the current workaround, and who's actually using it?
Who uses this tool every day, and what does their workflow look like right now?
What happens if this ships six weeks late?
What's already been tried, and why didn't it work?
Compare that to a partner who opens with your tech stack preferences and budget range. The content of the questions tells you more than the number of them ever will. If you're building your own list of questions to ask a software development company before you commit, start with the ones above and add whatever's specific to your situation. Pay attention to whether they take notes on your answers, too. A team that's genuinely building a picture of your business writes things down. A team that's already decided what they're going to propose doesn't need to.
What "you may not need this" sounds like
The strongest signal a partner can send is a willingness to talk you out of the project entirely. If a SaaS tool or a smaller fix would solve your problem, a partner who's confident in their value doesn't need to build you something bigger to prove it. A vendor incentivized purely by billable hours has no reason to ever say this. When one does, take it seriously.
"One thing that stands out in my approach is focusing first on understanding the client's business processes before proposing a technical solution. This helps ensure the solution not only works technically but also improves efficiency for the people who use it every day." — Renato Motikawa, Technical Product Manager, DevSquad
The technical product manager as the connective tissue
The person running discovery matters as much as the process itself. A technical product manager, someone with real development experience, can catch a feasibility problem in the same conversation where you're describing your business goals. A generalist PM or an account manager usually can't. They'll take the requirement back to engineering, find out it's harder than expected, and you'll hear about it three weeks later as a change order instead of a five-minute conversation on the first call. That gap is exactly why every DevSquad squad is led by a technical product manager with prior development experience, not a coordinator relaying messages between you and the people writing the code.
Red flags that predict a bad partnership
The red flags below aren't arbitrary. Each one is a variation of the same problem: a partner skipping discovery to get to yes faster. Watch for these during the sales process, before anything is signed.
A fixed-price quote before real discovery
A confident, fixed number delivered in the first meeting should worry you more than it reassures you. Accurate scoping takes real discovery time. A vendor who skips that step is either padding the estimate to cover the unknowns they haven't found yet, or planning to make up the difference in change orders once you're already committed.
Neither outcome is good for you. In the first case, you're overpaying for risk the vendor hasn't actually assessed. In the second, you're signing up for a relationship where every new requirement becomes a negotiation instead of a conversation. A partner who wants to scope you properly will usually say so directly: they need a short paid or unpaid discovery phase before they can give you a number they're willing to stand behind.
Vague answers about who actually builds it
Ask directly who will be writing the code, not just who's running the sales calls, and pay attention to how specific the answer is.
Who's actually assigned to my project? A direct partner names roles and, often, names. A vague one talks about "our team" without ever getting concrete.
Where is the team located, and does that change during the project? This isn't about onshore versus offshore. DevSquad is upfront that its developers work from Latin America. The point isn't location, it's whether the partner will tell you plainly who's doing the work and whether that changes once the contract is signed.
No pushback on your roadmap
This is the strongest red flag on the list. A vendor that takes every feature request at face value isn't being agreeable, they're avoiding the harder, more valuable conversation. A real partner pushes back when something in your roadmap won't move the needle, even when that's not what you want to hear in the moment.
Watch for this specifically during the proposal stage, not just the sales calls. A vendor who nodded along to every idea in the discovery conversation and then handed back a proposal that includes all of it, unchallenged, has told you exactly how the rest of the relationship will go. You'll get what you asked for, feature by feature, and no one will ever tell you which of those features weren't worth building in the first place.
"Instead of just managing a standard roadmap or accepting feature requests at face value, the real function is to act as a strategic consultant. I enjoy understanding the client's real challenges and needs, asking the right questions, and working together to find solutions that create value for both the business and its users." — Matheus Fonseca, Associate Product Manager, DevSquad
When the right answer is "you don't need custom software at all"
Sometimes the best outcome of vetting a partner is walking away from the project as it was originally scoped, and a good partner will tell you that themselves.
A mid-market logistics operator came to DevSquad ready to sign for a full custom dispatch platform to replace three disconnected SaaS tools. Discovery revealed that two of those tools were actually working fine. The real problem was a single manual handoff between dispatch and billing that nobody had ever mapped out. The final scope replaced one workflow instead of three systems, cost a fraction of the original budget, and shipped in under half the original timeline.
That's the outcome you're protecting when you vet for discovery-first thinking instead of a confident pitch. A partner motivated only by the size of the contract has no reason to find you a smaller, cheaper answer. A partner worth signing with will find it anyway, because they're solving your problem, not filling their own pipeline.
This is especially relevant if you're evaluating a partner to replace an expensive or outgrown SaaS subscription. Not every part of that stack is actually broken. Sometimes one tool is genuinely working, one is redundant, and one is the real source of friction. A partner who tests that assumption before proposing a full rebuild is doing you a favor that a vendor racing to a signed contract never will.
A simple framework for evaluating your shortlist
You don't need a comprehensive checklist to run this well. If you're looking for a simpler way to think about how to choose a custom software development partner than a forty-point scorecard, this is it: five questions you can ask directly in a sales conversation, and a sense of what a strong answer sounds like next to a weak one.
"What would you push back on in this scope?" A strong answer names a specific feature or assumption. A weak one is some version of "we'll build whatever you need."
"Who will actually be writing the code?" A strong answer names roles and seniority directly. A weak one stays vague or gets deflected back to the sales conversation.
"What's the smallest version of this that solves the core problem?" A strong answer proposes something smaller than what you asked for. A weak one quotes the full scope back to you as-is.
"Walk me through a project that didn't go as planned." A strong answer is specific and explains what changed. A weak one has no real example, or quietly blames the client.
"Why does your timeline look the way it does?" A strong answer ties the number to their planning process, often something faster than the 12 to 18 months a lot of agencies default to, because heavier upfront planning and AI-assisted development cut out wasted cycles later. A weak answer is a round number with no reasoning behind it.
Use this during the sales process itself, not after you've already signed. If you want a more formal version of this exercise, our guide on how to write an RFP for custom software development walks through the same idea in more structured detail.
Use this framework to see whether your potential partner is a good fit:
What to ask | Strong signal | Weak signal |
|---|---|---|
"What would you push back on in this scope?" | Names a specific feature or assumption | "We'll build whatever you need." |
"Who will actually be writing the code?" | Names roles and seniority directly | Vague, or deflects back to sales |
"What's the smallest version of this that solves the core problem?" | Proposes something smaller than what you asked for | Quotes the full scope back as-is |
“Walk me through a project that didn't go as planned." | Specific, explains what changed | No real example, or blames the client |
"Why does your timeline look the way it does?" | Ties the number to their planning process, often faster than the 12 to 18 month norm | A round number with no reasoning behind it |
When I started running discovery calls at DevSquad, I promised myself we'd never take orders without pushing back. If a client asks for a feature that won't move the needle, my job is to say so before we ever write a proposal, not after we've already billed for it.
How discovery and delivery actually work once you sign
The vetting criteria above aren't abstract preferences. They're a preview of the workflow you're actually signing up for. A lot of vendors treat discovery as a phase that ends once a contract is signed and development begins, and that's exactly where the discovery-first behavior you vetted for during the sales process tends to quietly disappear. At DevSquad, discovery doesn't end when delivery begins. The two run as parallel, continuous tracks for the life of the engagement:
Ongoing discovery sprints that keep testing and refining what should get built next
Delivery sprints running alongside them, building what's already been validated
No single one-time kickoff phase that discovery has to survive on its own
That structure matters because your business doesn't stop changing once a project kicks off. New information surfaces, priorities shift, and a partner who only ran discovery once, at the very beginning, has no built-in way to catch that and adjust. If the partner you're evaluating can't describe something like this when you ask how they handle a changing scope mid-project, that's worth pressing on directly. You can read more about how discovery and delivery run in parallel in our breakdown of dual-track agile.
FAQs about vetting a custom software development partner
For most mid-market projects, plan on two to four weeks of real conversation before signing, not just a single sales call. That's enough time to see whether a partner asks good questions consistently, not just in the first meeting when they're trying to win you over. If a vendor is pushing for a signature faster than that, ask why the urgency.
A vendor builds what you ask for and stops there. A partner pushes back when your roadmap won't get you the outcome you want, and will tell you when a smaller fix solves the problem better than a full build. The difference shows up earliest in how they run discovery, before any code gets written.
Yes, but treat the quotes as a secondary signal, not the primary one. A fixed number delivered before real discovery tells you less about cost than it tells you about process. Compare how each partner arrived at their number, and how many of your business's specifics actually shaped it, before you compare the numbers themselves. If you want a deeper breakdown of what drives those numbers up or down, our guide on custom software development costs covers it in more detail.
Most projects that go sideways with a partner don't fail outright, they end up needing significant rework or a full rebuild once you switch. That's a common enough situation that DevSquad regularly takes on rebuilding an existing system after a prior partnership didn't work out. It's recoverable, but it costs more time and money than getting the vetting right the first time.
Ready to start the conversation with a partner who asks the harder questions first
The partner worth signing with will want to understand your problem before they ever name a price. If your last few conversations have felt more like a pitch than a real discovery process, that's worth paying attention to before you sign anything.
None of this has to feel adversarial. The point of vetting a custom software development partner this way isn't to catch someone in a lie, it's to find out early whether this is a team that thinks alongside you or one that's waiting to be told what to build. That difference decides whether the next year of this project feels like a partnership or a project you're managing from the outside.
See how DevSquad approaches custom software development and what discovery looks like from the first call.
Rafael Lunardelli is the CTO at DevSquad and founder of Pinguim Academy. With nearly two decades in software development, he specializes in scalable systems, DevOps, QA, and modern PHP development. Rafael has led enterprise projects at KPMG and now teaches thousands of developers through his Laravel-focused courses, conference talks, and online content.