In the past, we consulted startups on hiring remote development teams for their digital products. Hiring a team over building one from scratch in-house product can reduce costs and save time in early years of business. From years of experience, we generalised these 5 pointers that books often don’t talk about.
First and foremost, developers in your team need to be able to work in sync with you. Availability and responsiveness should not be confused with working in the same time zone. Even in the same time zone if the team is not responsive then they are as good as being anywhere in the world at any given hour.
About a year back, we did a small project with a health and fitness firm based out of Atlanta. We came in as a remote development team working with a +13 hours time difference. Our customers in Atlanta were fine with the time difference, in fact, they liked how their ideas would come to life when they would wake up the next morning. What they appreciated more was our responsiveness in their time of need. They always had a way to reach out to us at any hour based on the criticality.
Pro Tip: Try testing your teams’ responsiveness and availability by starting a fire in your workplace.
Remote development in a location that has a different culture can imply vacations/holidays for the team when others are in office and vice versa. Evaluate how these difference impact business. Is the cost that covered in the overall cost of hiring the team. How does business run effectively during those periods?
We were approached this fall to launch an app for travellers as a proof of concept. The app had to be released this Christmas when most of the western world takes time off and hence hiring local resources in the US would be hard. On the contrary, a team located in Tehri, India would be perfect for the job.
Pro Tip: Know when the team will take time off and how the business will run as expected during that time frame.
The development budget of a young business can fluctuate rather often and drastically. The product definition and scope may change calling for a higher spend or they may simply be lesser money for development because marketing needs it more. One may feel that it’s not likely to happen and that everything is planned and thought of but the reality is that it does happen quite dramatically during initial phases.
Pro Tip: Negotiate and be aware of the teams’ capacity in terms of cost and time to increase or decrease the size based on the need of the business.
In one of the clients meetings, our customer opened up about a bitter experience. Before working with us, they were working with another firm to conceptualise and build their product. In the initial phases, the firm provided very affordable costs for conceptualising and designing the product. Once the product reached the development phase the firm requested a much higher cost for architecting and developing the product further.
The quality of product poor because it lacked in user experience. They had to re-do the product. In hindsight, they would prefer to work with moderately expensive designers at the cost of very expensive developers. To make things clearer, the chart below depicts a cost breakdown of a Flat Pricing team compared to Development Heavy team in terms of expertise. The overall cost is the same amount but the quality of UX would be better (with higher priced design) in a Flat Pricing team.
Pro Tip: Evaluate what kind of a expertise the product needs and what is the cost that comes with it. You can go for a team that has very experienced developers or very experience designers or both moderately.