Your first call with a dev shop – creating a good first impression
Apart from providing a high-touch concierge type service for finding you the right developer, we’ve been in the business of curating dev studios all over the world for about 4 years now. Let us tell you a thing or two about interacting with dev shops and evaluating them.
What we’ve found is that the outcome of the first call goes a long way in determining the outcome of the project itself, and whether it can take off in the first place. You need to let them know how serious you are about your project, and what kind of effort you’ve put in so far.
Before you start speaking to dev teams, make sure you’re ready with a write up about your product. This could be in the form of a requirements specification or just a simple description. Anyone who reads the write up should immediately get some clarity about your product. Developers today understand the need for confidentiality in a highly saturated market where new ‘disruptive’ apps are creating trends everyday. It’s okay to get them to sign a Non-Disclosure Agreement before speaking to them about the product.
Not having prerequisites like these could do you more harm than good. It’s not very likely that they’ll take you seriously if you tell them about your product over a call without having anything to refer. Here, prototypes or wireframes work really well in getting the developer to understand your vision about the product’s look and functionality.
On the call, it’s always good to start with a brief introduction about your background and the reason you’re building this app or website. It could be for an already existing business(tell them about the business if so) or for a new startup. This builds trust as they know that you’re really interested in doing it.
Validating relevant experience and skill level isn’t that simple but there are still a few ways of getting an insight into this as a non techie. Do some research on the best back end technology that will enable your product to perform well and work at scale. For example, Node JS is a good choice for back end for On Demand Service Apps like taxi booking services. Many developers are likely to suggest tech that they’re good at rather than something that would fit the product. This doesn’t necessarily mean that they’re taking the easy way out. It’s mostly them proposing a method of product development with the least risk given their skill level and the resources available.
Once initial round of conversations are over, getting references from the teams is always a good idea. Their past customers are the best way to know how it would be to work with them. You can also get inputs on the best way to engage them and bring out their best.
Estimating the cost and resources required is something that every team does differently. Here’s an annual report we publish on app development pricing. Hourly rates vary across teams. As you talk to relevant teams with a concrete set of features in hand, you’d see a marginal difference in the work estimates from the teams.
These would be in the form of number of hours/days of work done by resources who’ll be involved at different stages of development. Once the total number is calculated, they would multiply that with their blended average hourly rate to arrive at the tentative cost. If you’re confident about the approximate number of hours a team would need, asking for a team’s hourly rate early on is a good idea. It would save you and the team a lot of time if the rates won’t work.
You must remember that this is another case of 2-way evaluation. As important as it is to pick the right dev shop, it’s equally so that you’re the right customer for them. Don’t shy away from asking questions, but equally, be open & frank when answering theirs.
Pravir Ramasundaram is our in-house content writer here at ContractIQ. Keep coming back to read more of his articles on mobility & outsourcing.