How to Evaluate a Development Partner

There are many reasons that businesses use outside partners to develop innovative software solutions. Some need additional capacity to surge resources on a critical project while others simply lack the expertise in-house to accomplish what their growing business demands. Regardless of needs, companies are searching for development partners who are easy to work with and who can deliver a quality and affordable solution in a timely manner. While there are undoubtedly many ways to go about finding the perfect fit, here are some recommendations for successfully evaluating a development partner.  

Start with Your Network

Like the old saying goes, “people do business with people they know, like, and trust.” Referrals are powerful sources of information and you can streamline the evaluation process by building on a foundation of implicit trust. If your network is lacking development partner opportunities (cough, cough, over here!), you will need to assemble your own list of organizations that satisfy your base criteria (i.e. company values, location, reputation, stated capabilities).

Avoid Order Takers

Before embarking on a project, a common temptation is to build a comprehensive list of requirements and have development partners provide cost estimates based on your lengthy list. I would encourage you to avoid this process if possible. You know your business better than anyone, but you likely do not know all the best ways to create an optimal user experience or the most current approaches to building software applications. You want to lean on your development partner to provide solutions for these based on your budget and your users. If you attempt to make all of these decisions without involving them, you will be missing out on some of the most important services the development partner provides.

Evaluate Your Own Team

When selecting a software development partner, you should consider evaluating your own team first. Do you have someone adept at translating the needs and processes of your business into technical application requirements? If not, you need your partner to bring strong Product Management resources to the table. Do you have someone that can design an optimal user experience? If your team is lacking experience in that area, you need a UX designer. Do you have someone with significant experience in software architecture and design? If not, you need to find an architect. Is there someone on your team that understands Agile development practices and can keep your project on track and on budget? If not, you need a Release Manager. All of these roles (and more!) will be needed to build a quality solution, and if there are gaps in your in-house team, you’ll need a partner who can fill those holes.

Consider the Location of Your Resources

You need to inquire about where the resources are located and how the company is working in a COVID-19 environment. Due to the numerous micro-decisions made by every member of a development team, Artisan believes that every team member should experience the physical environment where the software will be used. In addition, meeting face-to-face also builds trust and personal connections much quicker than doing so virtually. The faster the entire team gels, the sooner they become more efficient. Philosophically, Artisan still believes this, but COVID-19 has required us to adapt and create workarounds.

Look for Philosophies that Align with Your Organization

Joining forces with a development partner that follows best practices and utilizes development philosophies that align well with your organization is critical. Today, Agile development is a must for most projects, along with Continuous Integration and Continuous Deployment (CI/CD). You should inquire about these elements during the interview process, and understand how Product Managers will translate what they see and hear into artifacts for the rest of the team. You should expect to hear about personas, journey maps, storyboards, wireframes, or mood boards. UX designers should be able to create different levels of “clickable” prototypes, and depending on the project, the detailed graphical work (and code) can often be used in the finished product. The Release Management team should talk about Agile as a fluid practice based on the needs of the team. Inexperienced teams will assume all projects should be done in sprints or on a Kanban board. Ask how long their daily standups typically last. If they indicate anything more than 15 minutes, you should dig into that and understand why. Ask about the types of reporting they can provide you. Burn down charts, time reports, and cost projections should be common things they talk about.

Ask About Code

In terms of actual code, Viagio practices Domain Driven Design (DDD) on most projects and it serves as the foundation for how we model and design systems. Domain modeling is not a new practice nor is it an exact science, but it is amazing how many people struggle with it. When an architect or senior engineer shows you a domain model, it should contain terms that are very familiar to you and you should easily be able to understand the relationships between objects. If it does not make sense, something is wrong. If you have strong architectural resources on your team, you should have them ask the consultant what their approach is to modeling and layering systems. You will want to look for consultants that understand the SOLID principles, loose coupling, OO, interface driven design, inversion of control, dependency injection, and others.  You might also consider asking them what their thoughts are about Object Relational Mapping (ORM) tools or code generation in general. There is no right or wrong answer here, but it is a good question to understand how they think about speed vs. control. 

Prioritize Communication

Communication surrounding complex topics is critical to any project. Really good code reads like poetry and working with it is fool proof. One test I like to give people is to have them explain what the cloud is. They will struggle a little at first to figure out where to start, but given a few minutes, they should be well on their way to describing aspects of AWS, Azure, GCP, etc. If they don’t, they probably don’t understand it themselves or they aren’t very good communicators.  Either way, it is a red flag.

Chat About Security

What is their philosophy about identity and login? In general, logging in is one of the top targets on an application’s threat model. Do they want to integrate with an existing identity management system or roll their own? (Hint: do not roll your own unless you have a really, really, really good reason to do so.) You may also ask them their thoughts regarding data protection (at rest and in-flight), PHI, PII, PCI, COPPA, or other standards that are relevant to the project.

Don’t Brush Over Technology Expertise

Don’t assume anything about their know-how in the technological space. Viagio has more of a purist approach to development and we stress fundamental patterns and principles over standardizing on one technology stack. This not only maximizes the projects we can handle, but it promotes one of our core principles of using the best tool for the job. “Best” may be different from one client to the next, even if it is the exact same project. You may not want to introduce an entirely new technology to your organization if you don’t have to.

What About Price?

You may be saying to yourself, “what about price?” That is of course a factor, however, as you start to get answers to the questions above, you will quickly realize that you typically get what you pay for. Many projects start with the lowest bidder and then need major overhauls 6 months later. Spend the dollars where your team needs the most help or where you want to invest the least time managing.

Why are you seeking a development partner? What are your company’s needs? Finding the right fit is no easy task, but it is well worth the time and energy spent asking all of the right questions. Speak up, go with your gut, and make the smartest decision for your future.