Can You Trust an Outsourced Software Development Team?

Can You Trust an Outsourced Software Development Team?

You can learn a lot during the onboarding process.

Trust is the number one factor that keeps organizations from outsourcing software development. Especially for those who have historically relied on an in-house team, this is a huge mental hurdle.

That isn’t to say that this obstacle is unfounded. There are tons of shady dev shops out there, and there are even more that want to do good work, but for one reason or another, fall short.

How then, can an organization ensure that they will get good quality work, and also make sure their infrastructure is secure when hiring an outside dev team? After all, onboarding a new team requires giving away what seems like a lot of control. You are handing them keys to server access, user information, passwords, permissions, or whatever they need to jump into the project. The key is asking the right questions to build that initial level of trust.

1. Find the Right Team

Sounds obvious right? How do you do that? First, decide what you are looking for. There is a classic triangle: Cost, Quality, Speed… pick 2. This is pretty true and knowing which two matter the most to you is going to greatly change the team you are looking for.

Cost: If you need to keep the budget as low as possible, that means that you are going to be getting a team with less experienced devs, you probably will be doing your own testing, and you will need to take a more active role to make sure the project is on track.

Quality: If you want high quality, then you can start to get a lot pickier. 

• What is their testing process? 
• How do they manage environmental security? 
• How often will you be communicating? 

You should be asking these types of questions no matter what, but if you are aiming for a more experienced team, then they should have much more solid answers.

Speed: If you have a tight timeline, then a few things are going to be critically important:

• Testing is a big one. Going multiple rounds with lots of bugs is a good way to miss a deadline.
• Have they done this before? Again, if speed is super important, it might be best to find a team that can borrow from their other projects to get the basics up and running in a hurry.
  
  While this is an obvious step, organization’s often leave this out of the vetting process. Ask the companies you’re interested in working with how long they’ve been in business, and get them talking about their projects. A good agency will always get excited about their past work. This isn’t just a job, it is a passion and it will show.

Experience: While this is outside of the “triangle”, experience is a key factor in building comfort and trust with a team.

• How long has the team been building software? 
• Is the team consistent or is it just a bunch of floating contractors who come and go? This part is really important. If the team is in constant flux, then they won’t work together as smoothly as one that has been together for a while. It makes a difference. 

Another key part of experience is related to the infrastructure of a project. While you may have a “secret sauce” that makes your idea unique, most of your project has been built before. Payments, authentication, dashboards, and the like are pretty common in the software world so think about what your project needs and see if the team has worked with those components before.

2. Know Your Security Needs 

Are you selling something or just giving information? What standards does your industry require when it comes to securing your data? How nervous are you about data security / breaches / etc? 

When it comes to bringing on an outside team, you need to know, in general, what your security needs are and be able to ascertain if the dev team can provide what you need. Now, this doesn’t mean you need to be an expert on all of this, but you should read up on the basics.

For instance, if you are selling something online (either a good or a service) you need to know what PCI compliance is at a beginner level so that you can make sure your devs are securely building your software. Even with the basic knowledge, you will be able to ask good questions of your prospective team and easily figure out if they know what they are talking about or if they are just “blowing smoke”.

Also, knowing your comfort level with data security is important. Security is a deep, deep hole and you can spend a lot of development time here without getting a lot of value. Basic standards and practices will take care of most needs, but only you can say whether or not that will work for you.

Again, the end goal is to build trust with a new team. Big Pixel has a great reputation for being able to communicate what we need, and don’t need, from your company or existing IT team. You will know how we are going to use that access and what we will do to keep all your private information secure. This comes from our experience and commitment to being transparent to build that aforementioned trust.

3. Keep Things Within Range

Different areas of the world require different security protocols. You’ll need reassurances that the team you are onboarding is experienced and comfortable working within these parameters. This makes for a smoother onboarding that requires less time educating them on specific geographic laws or expectations.

One example would be the laws in parts of Europe that require websites and apps to disclose all cookies or ways it stores user data while allowing the user to opt-out before continuing to view the content or use the app. There are similar laws and protocols required if you’re doing business in California. 

While there are always cheap options available, those options might also come with additional risks. For example… What do you do if you hired a less experienced team from around the world and that team is not able to meet your region's legal requirements?

Would you have an avenue of recourse to get your code or your money back? Would you then have to restructure all the secure information you just gave access to and look for another new team? It might be better to bypass these non-optimal scenarios and keep an eye out for any red flags that make you feel uneasy. 

So, the question is, can you trust an outside dev team?

The answer is a resounding yes. Use your judgment and ask the right questions to ensure that you’re working with the right people. In the end, trust your gut and go with a team that communicates clearly, is transparent with their intentions, and has a reputation built on experience.