LookFar Labs4 February 2016

How to Tell if a Potential Software Development Partner is Right For You

Questions to ask, and answers to look for.

Choosing the wrong technology partner is among the costlier binds that startup founders can encounter. So, why does it happen so often? One major issue we’ve noticed: not knowing the right questions to ask.

It’s happened to the best of us. Your prospective developer seems confident when you sit down to interview him, but when it comes time to execute actual work he just can’t deliver. Best case scenario, you’re able to cut ties with a limited financial loss. Worst case scenario, your war chest is drained and your code is permanently handicapped. Unfortunately, many of our partners come to us after this type of interaction, feeling burnt out and understandably a little betrayed.

So we’ve created a handy dandy micro-interview for you to help vet any team you’re considering bringing on board. We’ll be giving you the tools you need to evaluate a software development partner’s ability to manage a product and work with you as a stakeholder. If you’re about to hire someone, make sure you at least have them walk you through a few of the following questions.

Q: How will costs differ if I opt for cross-platform mobile app development instead of picking either iOS or Android?

A: “Costs will be much higher”

IOS and Android logos

If a person or team says otherwise, consider this a red flag. Even if they plan to use a product like PhoneGap or Xamarin to save development time, they aren’t a wizard. Different requirements of the product mean creation of additional assets, setting up additional code – for which assets are pulled and served dependent on the device – and testing on a variety of products. If you’re budget-conscious, a good dev team will help you figure out whether iOS or Android is a better first step towards capturing your target audience.

Q: Can you send examples of previous work? What parts of this project did you contribute to specifically?

A: “Sure, here’s a portfolio. I’ve worked on…”

We always recommend asking to see examples of previous work. Not only will this give you a good sense of a developer or a team’s technical capabilities, it will also show you their attention to detail and ability to see a project through to completion (consider half-finished projects a yellow flag). Make sure you ask what their specific role was on the project. They may be showing you work that was built collectively, which isn’t representative of their personal skillset. Even if you’re talking with larger, established companies, they may work with an external design firm, or partner with a hosting company. Make sure you know which aspects are handled internally and which will be outsourced.

If you’re looking to build an app, pay particular attention to any work they’ve actually published to either the Apple Store or Google Play. Published apps are apps you can personally test, and they also give you a chance to gauge the reaction of a larger audience of users to your partner’s work.

It’s also important to know how this company works. Even if you trust their development team, you need to feel confident that they will:

  • correctly interpret your vision
  • keep in close communication with you
  • meet deadlines
  • respect your budget
  • move forward in a way that’s best for you, not the easiest for them
  • Provide needed services – such as maintenance – even beyond an initial build

Q: Do you have a specific process for gathering business requirements?

A: “Yep. Here’s how it works…”

If a team says “we’ll talk it over” or “we have a brief meeting,” consider that a red flag. Requirements gathering should be done formally, with the results documented. Requirements can be gathered in the beginning or throughout the project, just make sure there’s an established process for gathering requirements and documenting changes over time.

EP wireframes

At the beginning of a project, the team will likely produce wireframes or workflows, which should then be thoroughly discussed and reviewed by you before they write a lick of code. Requirements gathering should also be ongoing, with the current state of the project assessed and reviewed, as requirements always change throughout the development lifecycle.

Q: What happens if I change my mind about a feature or design?

A: “We expect changes will occur and have that built into our budget and timeline”

There is only one certainty in software development, or any large project, really: requirements will change. Any experienced team will understand this and have a process in place for dealing with this inevitability. Ask for more details about how they’ve handled clients in the past who have had major design or scope changes mid-project.

Q: How does your team handle product management?

A: “We’ll have a designated employee act as product manager”

Product management must be a priority with a designated person for communication. Since you’re not an expert, the communication about timeline, requirements, scheduling, product design and other details is crucial. You’ll be learning throughout the process of developing your idea into a product. Good project management will make that process easier and faster. The last thing you need is to be frustrated with confusion over incomplete requirements gathering, vague time estimates or surprises like ‘That feature? You never said you wanted that done.’

General aspects of product management can include:

  • Communication
  • Scheduling & timelines
  • Requirements management
  • Change management
  • Recording key design decisions
  • Maintaining the budget and scope of the project

A good rule of thumb is that a typical Product Manager handles 2-4 projects simultaneously, depending on the size. If your project is large and will be requiring more than 2 full-time developers to complete it, your PM should really be exclusive to your project, or at most, handling one other client.

We hope these questions will help you make an informed and confident decision when choosing a tech partner. Whether it’s us or somebody else, you deserve a development team who can do what they say they can do!

Written by

Molly Hegarty

Signal-Based Selling FTW with Creative Service Agencies Signal-Based Selling FTW with Creative Service Agencies Build vs. Buy: Third Party or Custom-Developed Software Build vs. Buy: Third Party or Custom-Developed Software