In our last post Subhi talked about all the things we considered in order to arrive at our decision to outsource the initial stages of Kanari’s software development. Though we put a lot of thought into that phase we knew that finding a suitable software development partner would prove to be a much more intensive exercise. Jumping into bed with a development partner was not something we took lightly because once work has started and initial payments have been made you don’t want to be in a position where you need to consider firing your development team and handing the project over to a new one. I’ll use this post to talk about the steps we took and all the things we kept in mind..
Creating a project brief
The first thing we did was create a detailed project brief. This sounds like an obvious first thing to do and that’s because it is. What’s important though is how the project brief is structured. It needs to be able to answer the majority of high-level questions a development team could potentially ask. Ours had the following high-level structure:
- Introduction to the product and a high-level description of the business
- Descriptions of how we envisioned the various user groups (users, customers and us) interacting with the platform.
- Simple diagrams showing how we envisioned the high-level architecture of the platform.
- Functional descriptions of each of the architectural components
- Various usage scenarios
- Project deliverables
- Information to be contained in the proposal
Since we would be sending this document out to a number of different companies (around 10), but ultimately only employing one, we debated how much information to include in it. On the one hand it needed to be detailed enough in order to get fairly representative proposals from all the potential partners we would be reaching out to. On the other hand we didn’t want to give away too much information about our business idea because we did not want this document to fall into a potential competitor’s hands, however unlikely that scenario seemed. We did sign NDAs with all the companies we spoke with but at the end of the day all you can hope for is good faith and ethical behaviour from the people you deal with.
We protected ourselves a little bit by dividing our brief into two sections, an MVP project brief and a ‘Future Features’ project brief. The MVP brief described only Kanari’s most basic and core product features and functionality. Any third party reading this document wouldn’t have considered Kanari a very innovative or potentially successful product. The second document detailed future features we wanted built and implemented – features we believe Kanari’s success will eventually depend on.
Our plan was to get companies to submit proposals for the MVP project brief only and then evaluate them on that basis – we would not share the ‘Future Features’ document with them during the tendering phase. Only once we had selected a company would we then share with that company our Future Features document. This would then allow us to share the details of Kanari’s full short/medium-term feature set only with the company we would actually be working with. It did mean that the winning proposal would have to be revised after being awarded the contract but we figured that extra time would be a small price to pay for our ease-of-mind. On the flip side it also meant, however, that it was easier and quicker for companies to put together proposals for us since the MVP project brief was quite simple in nature.
Shortlisting software development companies
We shortlisted potential companies primarily if they were referred and recommended to us by people in our direct or extended network. For example, one of my INSEAD entrepreneurship professors that is based in Bangalore was able to recommend a development house to us and he was happy to facilitate intros to their management team. This was very helpful because our discussions with that company got off to a great start. The same is true for a Polish company that we spoke with. They were referred to us by a Polish friend of mine that worked with them for an internal communications app for his management consulting firm.
In addition we also initiated discussions with a small number of companies and development teams that we felt it would be really interesting to work with. These were companies that were written about in technology and software development related articles, actively mentioned in forums or kept their own well-written blogs fresh and up to date.
We did not consider any local companies in Dubai because we feel that, in general, they don’t compete well in the international software development market on quality, capability or price. We didn’t consider North American or Western European companies either because we feared that, in all honesty, as a startup we would not be able to afford them.
Selection criteria
To help us make a final selection we wanted to be comfortable with the answers to the following questions, in no particular order:
- Are we impressed with this company’s past work?
- Have they built anything we’re familiar with or anything similar to Kanari?
- Do they have the capability and resources to pull off our project efficiently?
- Do they have a good command of the English language?
- Are they within a few hours of our local timezone?
- Do we understand their culture and work/business ethic?
- Will we be able to afford the typical hourly rates of mid- to high-end companies in their country? (Poland ~$75/hr, Ukraine ~$25/hr – $30/hr, India ~$25/hr)
- Can we see ourselves working with them in the medium term if need be, say up to 2 or 3 years?
- Do we feel like they understand and believe in our vision?
- Do they quickly grasp our MVP concept and try to contribute their own ideas to it?
- Do they offer constructive criticism of our vision?
- Do they seem enthusiastic to work with us?
- Were they responsive during the tendering phase?
- Do we ‘click’ with them and do we generally have a good feeling about them?
- What is their availability like and when can they get started?
- Are they in-tune with startup culture and current trends?
- Do they have experience working with small-scale founders or are their clients mostly large enterprises?
- Did their proposals show enough detail and technical understanding and did they inspire us with confidence?
Final decision
In the end we decided to go with the company that was able to satisfy the largest number of the above criteria. Most importantly, we had established a good channel of communication with them during the tendering phase, they were very patient with us and all our follow-up questions, they were always pleasant (not all people we spoke to were!) and they came across as being strong on the technical/back-end side of things. They were not the cheapest though (you get what you pay for) and we were a little hesitant about their design, UI and UX capabilities. Subhi and I agreed, however, that these were things we could live with if we paid extra attention to them. So far that has proven somewhat challenging but I think that we’re managing things relatively well.