How to evaluate a software development company before hiring them.
As a startup or an enterprise, you might be in a situation where you need to hire a dev shop (aka a software development company) to either augment your workforce or even more still, develop an entire product from scratch. It’s a difficult situation especially if you are a boot strapped startup, and you realize that you may have one and only one attempt to make it work. You have found out a bunch of dev shops, and have gotten varying quotes, and levels of effort. There is also tremendous geographical variation in the shops, some are on shore, some offshore and some blended. They all have their best practices that differ from each other, yet they promise the same end result. Sounds familiar?
Well, how do you get out of this quagmire? Here is how::
1. Ask them if they can show you previous examples of similar work.
Do not ask them if they can do what you are asking for. Almost always, it will not be exact. But if they have done enough work, they will have an assortment of examples to demonstrate.
2. Find out if the developers are hired full time or if they are contractors.
A dev shop with full time developers reflects a permanency In their setup.
3. The developers that actually would work on your project -- Find out how long are have they been a part of the team.
If they’ve been with the dev shop for a few years, it means that the dev shop has a stable environment.
4. Find out if there are any areas where they will bring in outside help or any other partners.
This will tell you how knowledgeable they are. While this is not necessarily a bad thing, it helps you recognize smartness and experience. You will get to see if there is a clear rationale behind the approach towards software development. It is not uncommon for dev shops to bring in other dev shops for specialized tasks, say for example the dev shop may be specialists in application development and want to stay focused on it, while working with a partner to manage all cloud deployments.
5. Find out how many folks would be allocated fulltime to your project.
Ask if there would be direct communication between individual developers and you. If the answer is a yes, it goes on to show a lot of transparency between the dev shop and you.
6. Find out what tools use to track projects and go look up those tools.
The tools a dev shop uses for project management talks a lot about their internal practices. As a follow up, do not hesitate to ask them how they use those tools. If they really use those tools well, they will really be effusive about it.
7. For the initial, very first point of contact in the dev shop, see how well or how detailed of an understanding do they have about what they do. Usually this person is on the fringes of the core functioning of the company, and if they are knowledgeable enough, then chances are that the others in the team are going to be equally if not more knowledgeable. As with other types of businesses, there are a lot of “resellers” in software development as well where they are the front face to a dev shop but are just passing files. Long term this may not be a good thing for you especially in establishing a robust relationship with the developers and so this is a good way to identify such arrangements.
8. Ask them about their failed engagements.
Every dev shop has one (or at least one). If they say they don’t, then it’s time for you to hang up. If they say they do, see how objective they are about what went wrong, what they own up to and what they don’t. This will tell you how things would be as and when there are challenging stages in your project (and there will absolutely be at least a few).
9. Ask them how they handle changes to scope in the middle of the project.
Every dev shop has costs to cover, but if they are experienced enough, they will also know that change requests are a reality of every project, and that they should be in a position to absorb some of the additional work and be very clear on how much can they absorb.
10. Ask them if they have any problems maintaining code in your code repository instead of theirs. Again, if they are willing, this indicates transparency.
11. Find out what their leave policies and notice period expectation from their employees are.
This will give you an idea of what to expect if one of the resources deputed to your project decides to quit their job.
12. Find out if they are willing to provide references.
If they have done good work, they will absolutely be able to provide at least a couple references. If they have done this in the past, counter intuitively you will notice that while they may agree, they will want to exercise reaching out to their current or past clients only if they are sure that is the only thing preventing you from working with them. However, there is a caveat to note, if they have a very large portfolio, they may choose to absolutely not entertain requests for references. In this case, you may need to dig into linked in on your own to find out their client contacts.
13. If you happen to speak to the references, make sure the context of the relationship of the reference with the dev shop is at least somewhat similar to what you are reaching out to them for.
14. Look up linked in profiles for the dev shop and the key players you have known thus far.
Match this with your evaluation of them, when you spoke.
15. If you have spoken to other dev shops, then cross reference some of the information.
You don’t need to do a technical deep dive. You can easily find a lot of common phrases in both of communications for you to see a pattern. For example, both may use the word Agile. This is enough for you to look it up and quiz them more on it. Youtube is your buddy here.
16. Do a cross verification of response times and how detailed the responses are.
Some dev shops tend to often research and provide very detailed responses, and so they may not be the fastest. There will be dev shops that respond really fast but you may find yourself going back and forth a lot with them. If there is a lag in response and also the responses are brief, then stay away.
17. This probably may be the single most important point. Determine their business acumen.
No matter how well you document what is needed, there always will be gaps, and these will get filled up implicitly by the dev team. If the dev team does not understand the purpose of the product they are building, they will simply not be able to address these gaps effectively. You don’t want the devs to build what was just asked for, you want to product that is built with as much longevity and robustness to it, and this includes implementing robust business rules. So ask for and find out past instances where they actually contributed to the business and not just the technology.
18. Get to know their payment terms. This also tells a lot. If you want to take a fixed bid route, get to know the payment milestones. If the dev shop is transparent, you will see that the milestones are associated with clearly measurable deliverables.
That’s it. Hope this helps. Btw, this is an ongoing list, so make sure to come back every so often to see what more has gotten added to the list.
Or contact us if you have questions.
Client Alignment, Understanding the Client’s Vision, and Client Education: These are the foundational blocks of our value system that has consistently delivered success to our clients and to us.