To develop in-house or outsource?
Although much is written about the steps needed to set up a business in Europe or North America, we found it challenging to find similar information about the difficult decisions we expected we’d need to make in order to set up a business in Dubai. This is the first in a series of posts in which we’ll be writing about some of the challenges we face whilst building Kanari. I’d like to dedicate this first one to an important decision related to building the first version of our product, namely to hire a team and develop in-house or outsource the development to an external party.
When thinking about developing Kanari, we spoke to a lot of entrepreneurs on this topic and the overwhelming majority advised us to stay away from outsourcing – not to even try it! Most of them spoke from experience and their feedback was along the lines of: they’ll take you for a ride, charge you loads of money, deliver very bad quality code or in the worst case not deliver anything at all! That would really suck. But, on the flipside, an entire industry was built around outsourcing software development, so we figured there must be someone out there doing things right.
Our belief is that in a lot of situations when these types of projects don’t work out there is more than one side to blame – not just the contractor but also the entrepreneur. Unclear or badly thought out requirements, constant changes to the scope of work, and a lack of experience/know-how on our part are some of the things we felt could very easily lead us to a miserable and costly failure.
Taking all of these arguments into account, here are a few things we considered when weighing our options.
Conventional startup wisdom says this is the way it should be done and it’s how most startups seem to get going these days. From a pure business perspective it makes a lot of sense: you can keep your technology development (a core competency) in-house and you can take the necessary steps to build a solid team and company culture at an early stage.
In the long run these things could all prove extremely valuable but the obvious requirement is that you have one or more technical co-founders on your team. People who at the minimum can understand software and manage developers but ideally lead the design and development of the product as well. If we had people like that on our team then going the in-house route would have been a much more attractive option for us.
As engineers, both Edmond and I are familiar with database structures, development methodologies and some of the programming languages used to build internet and mobile applications. We are also aware, however, of what we lack. And that is hands-on experience in writing code, up to date knowledge of the latest development frameworks and some of the best practices typically learned from a career in software development.
We thought long and hard about bringing in a third, highly technical cofounder, but we were (and still are!) concerned that finding the right person who shares our vision and is willing to dedicate their time to a startup may end up being a long, drawn out process. That’s not to say that we aren’t interested in bringing somebody like that on board. On the contrary, we’d be more than happy for somebody to join the founding team as long as there’s a good fit.
Moving on, there was an additional point to consider if we wanted to develop our product in-house. As a startup in Dubai it’s really expensive to hire a team – at least at such an early stage. In order to bring on full time employees we’d have needed to incorporate the company, get an office (although we probably could have gotten away with a flexi desk at one of the free zones) and pay for employee visas. This would have easily costed us upwards of AED 40k and taken at least 2 months. All of this before having a single line of code! A hefty investment for no viable product or measurable results… not very lean, if you ask me.
This is surely the unconventional approach, by global startup standards, but definitely one we wanted to consider. By outsourcing the initial development of our product we were hoping that we’d be able to tap into a pool of talent rather than depending on one or two individuals. We were also hoping that outsourcing would give us access to business analysts, architects, designers, front- and back-end developers and testers. These are people who have been at it for years and are up to speed with the latest technologies because their job requires them to do so in order to stay competitive in their industries. We felt that they could potentially add a lot of value to our idea by virtue of their past experience, maybe even point out valuable features we had not thought of. Moreover, we would only pay them for the time and effort required to get the job done.
That said, we had to keep in mind some of the drawbacks. Apart from the obvious factor of the team (most likely) being overseas thereby making coordination and communication that much harder, cultural differences could also play a big role in creating additional friction to an already strained long-distance working relationship.
We also expected that it would be challenging to identify reasonably-priced companies that had the in-house capabilities that we required, a solid track record and experience working with early-stage startups. Most importantly, however, we wanted to work with a team that we felt we could trust and that shared our enthusiasm for the product that is Kanari.
Finally, we were wary that outsourcing the development of our core product rather than building up these skills internally would mean that we’d need to have a clear handover plan in which we’d phase-in development efforts after our product was built. Until that happened, we’d have to be comfortable with the possibility that we’d be a lot less agile (in terms of building new features and pushing updates) and that any developers we decided to bring on board later would take considerably longer to get familiar with what has been built already.
After considering the pros and cons of each approach and factoring in the great advice we got from all the folks we spoke to (thanks guys!), we made the difficult decision to outsource the first version of Kanari. Our aim is to build a super lean product and go to market as quickly as possible to start collecting valuable feedback. Although we’ve found that the overall per-hour labour costs of outsourcing are higher than those of an internal team, time to market is a critical factor for us and we feel that working with a professional team that can get the job done quickly and efficiently makes sense. This, we believe, will allow us to gauge product/market fit, sign up customers and hopefully build up traction as quickly as possible.
So far, we have no regrets about the decision we’ve made. That’s not to say that it’s all smooth sailing though because we are in fact facing challenges on a daily basis. We’ll be sure to share some of those challenges with you in future posts.
A final word of advice
In closing, I just wanted to highlight some advice we got, which ended up working very well for us. Regardless of which approach you decide to take, there are two issues, which if addressed, can make the whole process of developing your product much smoother.
The first is to try to have somebody technical on your founding team. They don’t have to be a superstar coder, but at least someone who has either studied software at university or has managed software-related projects in the past. I fill this role on our team and still find it a challenge to deal with all the various issues and technical decisions that come up on a daily basis… I can only imagine how hard it would be for a team with zero technical know-how.
The second piece of advice that we are trying to follow is to dedicate as much time as we possibly can to thinking through the scope of our product, all the individual features we want included and the necessary business logic to make them work. We’re taking our time to document our requirements as clearly and thoroughly as possible because we know that if these aren’t spelled out correctly we’ll most likely have some serious headaches further down the line.
We’ve stocked up on Panadol just in case. 🙂