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

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

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

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

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

6) What involvement will be expected from me throughout the process?

7) What happens after my product has been delivered?

8) How does your process reduce my risk and increase my chances of success?

9) Can you provide references?

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.

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?

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.

Why It Matters: To get the right requirements — reflecting a complete understanding of your business and user needs — they’ll need a significant initial time investment and ongoing involvement. To ensure project success, your involvement should be much more than participating in updates and reviews. (That’s why communication is a separate question in our checklist.)

What involvement will be expected from me throughout the process?

What to Listen for: They should expect you to be involved, period, and give clear expectations of what that involvement will look like. This is one moment when “Don’t worry; we’ve got this” is the wrong answer.

What Else to Ask: Again, make sure their explanation is specific to your situation. It’s not helpful for you to know how it “generally” works. Ask how it will work with you.

What happens after my product has been delivered?

Why It Matters: All software products will require post-launch support. There’s no getting around it.

What to Listen for: Ensure they’re capable of providing ongoing support, helping you with problems, improvements needed, or new features if desired. Make sure they address who owns the intellectual property (IP) (e.g., the source code and related documentation) post-delivery — and that the answer is YOU. If they insist on retaining ownership and charging you ongoing licensing fees, are they really thinking about your best interests?

What Else to Ask: Ask about any warranties or other service guarantees they’re willing to discuss.

How does your process reduce my risk and increase my chances of success?

Why It Matters: You want to make sure they’ll bring a whole-business perspective to the project. If they can’t readily answer this question, you may want to rethink working with them.

What to Listen for: A good partner will give you a thoughtful answer that echoes key tenets of their development process. For example, they may mention user research, iterations, starting with an MVP, communication protocols, cost and quality control, scope management, or other items.

What Else to Ask: If they don’t bring up the items mentioned in “what to listen for,” ask them about them. Make sure they’ve addressed your specific concerns (e.g., market viability, cost or schedule overruns, team continuity, IP security/insurance).

Can you provide references?

Why It Matters: Duh.

What to Listen for: The only answer acceptable is “yes.” A “no” is a giant red flag.

What Else to Ask: Make sure you’ll be permitted to interview the references they give.

Title of the document