4 Questions to ask your Software Development Partner

Because application development projects are often expensive and high risk, finding a partner that you’re aligned with is incredibly important. One of the benefits of having worked as an agile software development partner for a good length of time is that we at Acklen Avenue have developed some expertise around assessing “fit” with our clients.

So here are a few questions we would recommend discussing with a potential partner as you search for the right one. There isn’t an objectively right or wrong answer, but the responses you’ll get will help you learn how aligned you are.

How involved will I be in the day to day development operations?

Here you’ll need to ask yourself first, how involved do I want to be in the day to day? In some cases, you may prefer to manage devs, QA, designers, and developers directly via a staff augmentation approach.

This approach almost always requires experience with software development team management. While this option may be less expensive, if you don’t know that role well or don’t have availability to do it, it can be exceedingly risky.

If indeed you don’t have the time, expertise, or will to manage the team, your software development partner needs to have a clear process for absorbing your product goals and grooming work with you on a regular basis, gaining feedback on real deliverables early and often. Many, many projects live and die right here, so if you choose a managed approach, this expertise is non-negotiable.

Speed vs. Quality: If you had to choose, which comes more naturally to your team?

You might have prejudices around test coverage minimums or pair-programming, so you’ll probably gravitate toward a firm that shares those preferences. But the most important thing here is to learn what their levers and capacities are when you really need them to flex that other muscle.

Often quality gets the short end, but it should be no surprise then that speed has to take a back seat to paying back tech debt. You’ll do best when you’re working with a partner that has muscle memory for both and can serve you well in either season.

Side note:

It is possible, even with experience, to incorporate quality practices while retaining respectable velocity. Experienced teams in work cultures that value quality will have whole took kits surrounding making these two values more compatible. This is something that we have particular passion for at Acklen Avenue.

What are a few of the most likely ways that this relationship could fail, and how can we prevent that?

This is a chance to listen to the strategy they have surrounding obstacles. Listen for whether or not they build resourcefulness and resilience to their application development relationships.

These types of relationships are often ambitious, and building great technology is hard. This question creates space to have clear communication, and to have tough but critical conversations when a need for a course correction arises.

Bonus intel that comes from this question:

If you cannot get your software development partner to share with you in any way this project could conceivably fail, either they do not have the level of experience you are looking for, or they will not be straightforward about challenges that do come up.

How does your process ensure that I learn of a problem or issue before it’s too late?

Know up front that this may be a tough question to get an honest answer on, just because our human nature leads us to resist sharing bad news.

What you want to listen for here are process-driven mechanisms that will allow you and your team to spot issues or areas of risk early on. The earlier you learn about a challenge, the more options you have in mitigating it.

If their answer is: “Because we will tell you! We promise!”, you may just want to press a bit more, and then likely continue shopping development partners.

What have you heard from potential partners that either closed the deal, or made you run the other direction? Are there questions you were glad you asked, or wished later that you did?