How to Vet a Custom Software Development Partner

Most guides on choosing a development partner are written by development partners, and it shows. They tend to describe an ideal firm that resembles the author.

Ours is organized differently. It is a set of questions and, more importantly, what each answer tells you about a prospective development partner. Honestly, some of them are among our least favorites to be asked; that’s exactly why they are the ones you should be asking before signing an agreement.

The stakes are worth stating plainly first. The Consortium for Information and Software Quality estimated the cost of poor software quality in the United States at approximately $2.41 trillion in its 2022 report, with accumulated software technical debt at roughly $1.52 trillion, tracked separately as a future cost rather than as part of that total. Those are macroeconomic figures and no single project moves them. They are useful here for one reason only: the expensive failures in software are rarely the projects that never shipped. They are the ones that shipped and then could not be changed.

Questions About the Work

Who Actually Writes the Code?

Ask for names, locations, and employment status. Ask whether the people in the sales meeting are the people who will be on the project. Ask what happens if one of them leaves mid-engagement.

The answer you want is specific and slightly boring. Vagueness here predicts vagueness later, and a firm that will not tell you who is doing the work before the contract is signed will not tell you afterward either.

What Happens When You Disagree With Us?

This is the single most useful question on this list, and almost nobody asks it.

You are trying to learn whether you are hiring judgment or hiring capacity. Both are legitimate purchases and they are not the same purchase. A firm selling capacity will build what is on the ticket. A firm selling judgment will sometimes tell you the ticket is wrong, that a feature is not worth its maintenance cost, or that you do not need the thing you asked for yet.

Ask for a specific instance where they told a client no, and what happened to the relationship afterward. If no example comes readily, you have your answer.

Who Owns the Code, and What Do We Have on the Last Day?

Ownership should be unambiguous and in writing. Beyond ownership, ask what a handover actually contains: repository access with full history, environment configuration, deployment procedure, credentials inventory, architectural decisions and the reasoning behind them, and a named person who can answer questions for some period after the engagement ends.

A firm that has thought about how you leave is a firm that expects you to be able to. That is the correct incentive.

Can We See Something That Went Badly?

Every firm has case studies. Ask instead about a project that overran, or one where the initial approach turned out to be wrong.

What you are listening for is whether the account has specifics and whether it assigns any of the responsibility inward. A firm that has never had a difficult project has either not had many projects or is not going to tell you the truth about this one.

Questions About How They Run

How Do You Estimate, and How Often Are You Wrong?

Ask how estimates are produced, who produces them, and what happens when an estimate is exceeded. Ask whether they will tell you at the point they know, or at the end of the sprint.

Fixed price and time-and-materials each have honest versions and dishonest ones. What matters is whether the pricing model matches the certainty of the scope. Fixed price on a poorly defined scope is not a transfer of risk to the vendor. It is a guarantee of a change-order conversation.

What Is Your Security Posture, Specifically?

If the answer is a badge, ask which criteria were in scope and what the observation window was. A SOC 2 report is a real signal and it does not mean what most buyers assume it means.

Also ask the operational questions the badge does not answer. Where do credentials live during the engagement? Will your production data ever appear in a development environment? Who on their side has access to your systems, and how is that access removed when someone rolls off?

What Do You Do About the Systems We Already Have?

Most mid-market work is not greenfield. There is an ERP, a system of record, an integration someone built in 2014 that nobody wants to touch.

Ask how they approach existing systems, and listen for whether replacement is the reflex. A partner whose first instinct is a rebuild may be right, and they may also be describing the engagement they prefer to sell. Ask what the option is that does not involve a rebuild, and whether they have delivered it.

Signals That Are Worth More Than They Look

• They ask about your constraints before describing their process.
• They give you a number early, even a rough one, rather than deferring it to a later conversation.
• They tell you which parts of the request they think are not worth doing.
• They can explain a technical tradeoff to a non-technical person without either condescending or hiding behind vocabulary.
• Their references include a client whose engagement ended.

One Thing Not to Over-Weight

Directory rankings and review counts are useful for building a list and weak for making a decision. Placement on many of them is influenced by paid participation, so look for a disclosure statement if you are browsing a directory. Use them to find three firms. Then let further research and initial discovery calls guide the final decision, rather than how they appear to perform on any given directory.

If you’re looking for a reliable directory for reviews of software development firms, we recommend Clutch.co. (Check out our profile while you’re there!)

Clear Function has been building custom software for mid-market companies since 2015. If you are working through a vendor decision and want a candid read on the questions above, get in touch. We will tell you honestly whether we are the right fit.