Choosing a Technology Partner: Seven Questions to Ask Before You Sign

Choosing a technology partner, whether for custom development, ERP implementation, managed services, or strategic consulting, is a decision that affects your organization for years. The wrong choice is expensive not just in direct costs but in delayed timelines, organizational disruption, and opportunity cost.

After two decades of working on both sides of the vendor-client relationship, I’ve identified seven questions that reliably distinguish partners who deliver from those who don’t. These aren’t the questions vendors expect, which is exactly why they’re useful.

1. What Percentage of Your Revenue Comes from Clients in My Industry?

This question reveals two things: domain expertise and client concentration risk. You want a partner with meaningful experience in your industry, at least 25-30% of their revenue, which indicates genuine specialization rather than occasional projects.

But you also don’t want a partner where your contract represents more than 15-20% of their revenue. Partners who are dependent on a single client make decisions to preserve the relationship rather than deliver the best technical outcome. And partners who lose a major client may face financial instability that affects your project.

The ideal is a partner who serves your industry deeply but has a diversified client base within that industry.

When we evaluated the AI chatbot market for a 50+ facility senior care operator, we tested three vendors before building a custom solution. The incumbent’s rigid approach could not handle the nuance of Medicare/Medicaid education conversations. Industry-specific experience showed in the details that a generic vendor could not address.

2. Who Specifically Will Work on My Project, and What Is Your Staff Retention Rate?

“Our team has over 50 years of combined experience” tells you nothing useful. You need to know the specific individuals who will be assigned to your project, their relevant experience, and whether they’ll be dedicated or shared across multiple projects.

Staff retention rate is the leading indicator of partner quality that most clients never check. A firm with 40% annual turnover will cycle through your project team multiple times during a year-long engagement. Every departure costs you knowledge transfer and ramp-up time.

Ask for the specific names. Ask to interview them. Ask what happens if they leave mid-project.

3. Show Me a Project That Failed and Tell Me What You Learned

Every honest technology firm has projects that didn’t go as planned. The answer to this question tells you whether the firm has a learning culture or a blame culture.

Good answers describe specific situations, the firm’s contribution to the problem (not just the client’s failures), concrete process changes that resulted, and evidence that the same mistake hasn’t recurred.

Bad answers deflect blame entirely to the client, describe failures in vague terms that avoid accountability, or claim that they’ve never had a failed project. The last one is either a lie or an indication that the firm hasn’t done enough work to encounter real challenges.

4. What Does Your Change Management Process Look Like?

Software projects change. Requirements evolve, priorities shift, new information emerges. How a partner handles changes reveals more about their project management maturity than any methodology certification.

You want to hear about a formal change request process with impact assessment (cost, timeline, risk), approval workflows that involve both the partner and the client, version-controlled scope documentation, and a mechanism for distinguishing between scope changes and scope clarifications.

If the answer is “we’re agile, so we embrace change” without describing a structured process for evaluating and managing that change, you’re going to experience uncontrolled scope growth.

5. What Is Your Approach to Knowledge Transfer?

The ultimate test of a technology partnership is whether your organization is more capable when the engagement ends than when it began. Knowledge transfer isn’t a workshop at the end of the project. It is a continuous process throughout.

Ask specifically about documentation standards (what do they produce and when?), training approach (hands-on vs. classroom, who participates?), source code and configuration management (do you own it, and is it documented well enough for someone else to maintain?), and post-engagement support transition.

Partners who resist comprehensive knowledge transfer are either protecting future revenue streams or their work doesn’t hold up to scrutiny. Neither is acceptable.

6. Can I Speak with a Client Whose Project Had Problems?

Reference checks typically connect you with a firm’s happiest clients. That tells you their ceiling. You need to understand their floor.

Ask to speak with a client whose project encountered significant challenges: delays, budget overruns, technical difficulties. How the firm navigated those challenges, how they communicated with the client, and how the situation was ultimately resolved tells you what to expect when (not if) your project hits similar bumps.

If the firm won’t provide a challenging reference, that’s informative in itself.

7. What Happens When We Disagree About the Right Technical Approach?

This question probes the partner’s relationship with technical honesty. In healthy partnerships, the technology firm pushes back when the client’s preferred approach carries risk. In unhealthy partnerships, the firm builds whatever the client asks for, even when they know it’s wrong, because they want to avoid conflict and keep billing.

The answer you want to hear describes a structured process: the partner will present their recommendation with supporting rationale, listen to the client’s perspective, and if disagreement persists, document the tradeoffs so the decision is made with full information. Then they’ll execute whichever approach is chosen, without passive-aggressive “I told you so” if it doesn’t work.

What you don’t want to hear: “We build what you tell us to build.” That’s a body shop, not a technology partner.

Using These Questions

These questions work best when asked during the vendor selection process, not after you’ve narrowed to a single finalist. Ask all seven to your top three candidates and compare the depth and specificity of responses. Pattern recognition across multiple vendors quickly reveals who operates with integrity and who is performing.

JS Technology Solutions welcomes these questions, and any others that help prospective clients make informed decisions. If you’re evaluating technology partners for a healthcare, senior care, or professional services engagement, we’re confident our answers will demonstrate the transparency and technical depth your organization deserves.