When choosing a software development partner, not everyone knows what to look for.
The biggest mistake companies make is thinking software development is a one-off engagement. When you partner with a design and engineering firm, ideally, the relationship will be long term—that way, when bugs arise or new features are needed, your partner will be able to make these changes easily.
You could very well be working with your development partner for years to come. With this in mind, you should take great care when selecting one. Most importantly, make sure that the relationship is built on trust and honest, open communication.
Here are some of the most common mistakes people make when choosing a software consulting company:
1. They don’t ask about company culture.
Beyond technical ability (user research, UX/UI design, software engineering, etc.), the right partner will have a strong company culture, too.
Software development isn’t purely technical—the creative aspect is huge. A healthy company culture can be a strong indicator of the quality of creative work a firm is going to do for you.
Culture also relates to a company’s ethics, from diversity and inclusiveness to how a company treats its employees. Custom software development requires a very involved, close relationship. When you bring on a developer to help with a project, you’re welcoming their culture into your company. So choose wisely.
Don’t be afraid to ask: “What are your hiring processes?” “What is your culture like?” All of these company characteristics will factor into the type of work a partner does for you. If you don’t ask, it’s a missed opportunity.
2. They don’t explain their company mission and business model before development begins.
When companies approach Tandem, they often skip over who they are and go right into what they want. As a partner, it’s vital we understand the full context of the potential client’s business and needs.
We need more than just a checklist of features to design and develop great software. So we often have to slow them down and work to get a good feel for their industry climate, business model, competitors, customers, employees, etc. This helps us understand why we’re doing what we’ve been asked to do.
Taking the time to do this ultimately saves both parties time, money, and resources. Because through this vetting process, we can offer our perspective, set priorities, give suggestions as to what other features the client may want to implement, and make sure the client has proper personnel and infrastructure to utilize the software.
If a software development partner lets you skip right to the app or software you want to build, that’s a red flag.
3. They send walled-garden RFPs.
There are two types of requests for proposal: walled-garden and project briefs.
Walled-garden RFPs are, quite frankly, impersonal. Essentially, they restrict communication between the vendor and prospective client. They typically include an Excel spreadsheet with a bunch of boxes to check and basic questions to answer. Walled-garden RFPs make it difficult to determine whether a potential partnership would be a good fit, which is a waste of everyone’s time.
Project briefs, on the other hand, are essentially an invite to have an open conversation about a potential partnership where the two parties can gather around a whiteboard and really get to know each other. On the vendor side, it allows us to share our culture and demonstrate our interest in their business. It also provides plenty of opportunities for both the client and the vendor to pull the emergency cord if it isn’t the right fit.
I’ve seen people make the wrong vendor choice because an RFP didn’t allow for both parties to properly vet each other before moving forward. Please, companies searching for software developers: Inject a little humanity into your process and stop using walled-garden RFPs.
4. They expect to tell the vendor what to do, then disappear until the software is ready.
That’s not the way it works (or should work, at least). Software development between a client and vendor is a co-creative project, requiring daily back-and-forth communication and engagement—it’s not “set it and forget it.”
When you commit to a custom software development project, know that you’re committing a lot of thought and collaboration time to the vendor you partner with. Every decision should be made together, every move in lockstep. I’d much rather work with a micromanager who constantly asks about project status than someone who is entirely disengaged.
Really, you should view hiring a vendor as creating an extension of your own organization—now you have the ability to develop software, but you still need to provide direction and guidance. Your partner should be highly visible to you at all times, not disappearing for two weeks only to bring back work that may or may not be right.
5. They don’t realize they will rely on their developer throughout the lifetime of their software.
Once the software is delivered, you don’t shake hands with the vendor, say thanks, and walk away. Because as long as you’re using the software, it’s never truly finished. Your software will need security patches, updates, server maintenance, etc.
That is exactly why you need to be so thoughtful and intentional when hiring your next software development partner: You’re likely engaging in a long-term relationship. Software is a living, breathing entity that evolves over time. Over its lifespan, you and your partner will groom your software, optimize it, and make sure it remains healthy and functional.
Alternatively, a vendor may transfer the software to an internal team at the company at a certain point in time. In this case, a comprehensive knowledge transfer plan is absolutely vital—make sure your vendor has one in place from the get-go.
When knowledge transfer isn’t conducted properly, your internal team will be left with software they’re unable to modify and maintain. Nobody will want to touch it. And, as a result, it will eventually be rendered unusable.
Ideally, your internal team is closely integrated with your vendor from the outset. This way, your team will already be up to speed and knowledge transfer will be much easier once that time comes.
