VDevAppeo All articles
Custom Software Development

Read the Room Before You Sign the Contract: Five Questions That Expose a Software Vendor's True Intentions

VDevAppeo
Read the Room Before You Sign the Contract: Five Questions That Expose a Software Vendor's True Intentions

Photo: Richter Frank-Jurgen, CC BY-SA 2.0, via Wikimedia Commons

Every proposal deck looks impressive. The fonts are clean, the case studies are flattering, and the timeline promises exactly what you hoped to hear. But a well-designed pitch tells you almost nothing about how a development partner will behave eighteen months into a difficult engagement.

The real signals show up in how vendors answer uncomfortable questions. After years of consulting with mid-market companies across the United States—manufacturers in Ohio, healthcare groups in Georgia, logistics firms in Texas—we've noticed a pattern: the engagements that go sideways were usually telegraphed early, in the answers leaders didn't think to probe.

Here are five questions that cut through the polish.

1. "What Would You Advise Us NOT to Build?"

This is the fastest way to find out whether a vendor is selling or solving.

A partner who has genuinely engaged with your business problem will have opinions about scope—sometimes strong ones. They should be able to point to features in your wishlist that are speculative, redundant, or better served by an off-the-shelf tool. Telling a prospect "no" early costs an agency the deal sometimes, which is exactly why vendors willing to do it tend to be worth keeping.

Red flag: Enthusiastic agreement with everything. If the answer to "should we build this?" is always "absolutely," you're talking to a vendor optimizing for contract value, not your outcomes.

2. "How Do You Handle It When We're Wrong?"

Every custom software project hits a moment where the client's original assumption turns out to be mistaken. Maybe the workflow you described doesn't match how your warehouse actually operates. Maybe the customer segment you prioritized isn't the one buying.

Ask the vendor to walk you through a specific example—without anonymizing it into uselessness—of a time a client was wrong and how the conversation went.

Red flag: Vague assurances that "agile methodology keeps us aligned." Process language is not an answer. You want to hear about the actual conversation, the pushback, and how the relationship survived it.

3. "Who Exactly Will Be in the Room Every Week?"

The team that pitched you is rarely the team that builds for you. That's not automatically a problem—senior people win work, and blended teams deliver it. The problem arises when clients don't know who's actually accountable.

Ask for names, roles, and continuity commitments. Who is the technical lead? How long have they been with the firm? What's the turnover been on similar engagements over the past two years?

Red flag: "We staff projects from our talent pool as needed." Flexibility for the vendor often means churn for you, and every handoff leaks context you'll pay to rebuild.

4. "What Happens to Our Code and Our Knowledge If This Relationship Ends?"

It feels awkward to ask about the end at the beginning, but this question reveals more about a vendor's character than any reference call. A confident partner will have clean answers: your repository is yours, documentation is a deliverable, and transition support is defined in the contract—not held hostage.

Red flag: Hesitation, proprietary tooling buried in the fine print, or hosting arrangements that quietly make departure expensive. Lock-in designed at the start of a relationship is a statement about how that relationship is expected to go.

5. "What Does Success Look Like Six Months After Launch?"

Vendors who bill by the milestone think in terms of delivery dates. Vendors who build with you think in terms of adoption, performance under real load, and the second release.

A thoughtful answer will reference measurable business outcomes—reduced processing time, higher conversion, fewer manual touchpoints—and will acknowledge that launch is a beginning, not a finish line. If the vendor's definition of done ends at deployment, expect their attention to end there too.

Red flag: Success framed entirely in terms of deliverables and dates. That's a billing schedule, not a success definition.

The Pattern Behind the Questions

Notice the common thread: each question invites the vendor to demonstrate either curiosity about your business or commitment to their own pipeline. Genuine partners ask more than they pitch. They challenge assumptions, name risks unprompted, and treat your budget as a constraint to respect rather than a ceiling to approach.

None of this guarantees a perfect engagement—software is hard, and even the best partners will disappoint you occasionally. But the difference between a vendor who bills you and one who builds with you shows up early, in small moments of honesty that are easy to hear and easier to ignore. Listen carefully. The contract will thank you later.

All Articles

Related Articles

When Flexibility Becomes a Liability: The Hidden Fragility Inside Highly Customizable Software

When Flexibility Becomes a Liability: The Hidden Fragility Inside Highly Customizable Software

From Proof of Concept to Permanent Liability: The Hidden Cost of Shipping MVPs That Never Get Replaced

From Proof of Concept to Permanent Liability: The Hidden Cost of Shipping MVPs That Never Get Replaced

Fitting Software to a Broken Process: The Customization Mistake That Compounds Over Time

Fitting Software to a Broken Process: The Customization Mistake That Compounds Over Time