Swipe Left. 5 Flags to watch for when choosing your software team

Swipe Left. 5 Flags to watch for when choosing your software team

After contracts are signed and your new software team is kicked off there are many things to watch out for, but by then your money is already flowing.

What should you look for before choosing that team, when your time and financial investment with the consultant is still minimal?

Here are five flags that you should watch out for. These aren’t in order of importance, but are most likely in chronological order.

The important part is this; don’t hesitate to pull the plug at any stage – and ignore your sunk cost. Starting over at any of these pre-contract stages will be enormously cheaper and faster than trying to fix your bad choice after coding has begun. 

Many companies we talk to have wasted more than half their budget trying to fix a bad software team. Hire fast. Fire faster.

Treat it like dating. Swipe left at the earliest opportunity.

1. WEBSITE REVIEW

Start by looking at their website. It doesn’t have to be perfect – the cobblers shoes and all that – but it should make sense.  It should be written in your native language by a native speaker.

Don’t forgive websites with bad grammar or typos.  The website may be lacking content, but what is there will reflect their professionalism.  Just like on a resume, be strict about typos.  

The quality of the code you get from them will reflect what you’re seeing now.

2. FIRST CONTACT

You’ve reached out to them, perhaps via email or perhaps their toll-free number. What are your first impressions?  Were they quick to respond?  Was it a call center?

Remember this is speed dating. Every interaction with you is an opportunity to impress you. Not underwhelm you. You don’t need to be pushing the relationship because there are many alternatives out there.  

It should come naturally – you should immediately like and respect the people you’re talking to.  If not, move on – this is as good as it gets!

Other flags are techno-babble and mansplaining.  Depending on your technical expertise you may not know the deep technical terms, or be able to detect techno-babble (AKA B.S.) but the team you choose should not be talking over your head anyway.  

Beware of anyone trying to sound impressive with acronyms.  Even if you don’t know the technical details, you can still ask them to justify their choices between, say, Angular and React, or AWS and Azure.  Then just listen.

3. PRIOR WORK

While you’re on the call, ask them to send you a list of case studies of similar projects that they’ve done.  You don’t necessarily need case studies in the same vertical as your project, but it’s preferable. But don’t use that as a reason to say no, yet, because they still may have built the exact system you need for a different market.

Ask for client references too.  Call them all.  Really.  Ask them about their experience from start to finish.

  • How was the final handoff?  Or are they still in an ongoing relationship?  
  • Did all their launches go smoothly?  
  • Any missed deadlines?
  • How was their performance to budget?
  • How did they communicate problems?

4. ABOUT YOUR TEAM

When you met your prospective team, did you do it in person, or over video conferencing? More and more projects are handled remotely, and you may never meet truly in-person, and that’s ok.  But you do need to see them.  No phone calls, ever – use video.  

Like interviewing, you need face time. Watch expressions, body language, and what’s in the background.  Do you have a large national consulting company budget, or a scrappy startup GSD budget?  Choose appropriately.  

In all cases, judge what you see in front of you. Smooth sales people will not be involved during your project, even if they promise that. You may get “touchpoints”.

Don’t be sold on a company before you’ve actually met the technical team. And this is key – I mean the technical team who will be working on your project. Not the A Team they roll out for sales calls.  

You can ask, “Are you the team that will likely work on our project?“.

Ask for resumes of your team and principals, then review them closely. Look at their LinkedIn profiles, and see how many contacts they have, and how many recommendations.  How much BS is on there?  No photos on LinkedIn is a flag.

5. THE CONTRACTS

Finally, we get to the paperwork.  This is probably the most important part, because it will define your ongoing relationship. Until now, they are courting you. Now you’re getting married and any breakup gets expensive.  You can still walk away!

There are many things to consider here and I could blog about each of them, but to be brief, look for answers to these questions – they should all be YES!

  • Did they send a Mutual Non-Disclosure Agreement (MNDA) to you before your discovery meetings to protect you?
  • Was all paperwork sent via an e-signature platform like Docusign?
  • Did they send a Master Services Agreement (MSA)?
  • Did they send you a Statement of Work (SOW)?
  • Did the MSA/SOW define the following? undefinedundefinedundefinedundefinedundefined
  • Does your engagement include dedicated Project Management and have they spoken about communication cadence already? undefinedundefinedundefinedundefined
  • Have you both identified roles and responsibilities on both sides?

If you got this far without any hesitation – Congratulations!  You’ve done your due diligence and are ready to sign and start with your project kickoff – the first step on your next phase of engagement with your development team.

But don’t get comfortable or disengage just yet.. the first few weeks are critical. We’ll cover that in the next post.

Be sure to read our other post How Much to Build a Website to validate quotes you might receive.


James Shaw

About James Shaw

Co-Founder and Chief Operating Officer

James has been professionally programming for 30 years starting in C, C++, and moving to C# in 2000. He has received the ASP.NET MVP award 3 times and was a founding member of ASP Insiders. His recent roles have been less programming and more helping engineering teams improve, in roles such as Director or VP of Engineering.

  • Responsible for leading over 100 software engineers
  • 3-time Microsoft ASP.NET MVP Founding member of ASP Insiders
  • Owned, built and exited 3 startups
  • Started a charity with his wife to help women protect themselves from violence, Beating Violence
View author