What I learnt from Outsourcing a DIY matrimonial Start Up

What I learnt from Outsourcing a DIY matrimonial Start Up

Friday January 22, 2016,

8 min Read

Outsourcing: I spent eight years with Monster in Prague, first as a Quality Professional and finally as an Associate Manager, before returning to India. My startup adventure began three years ago when startups weren't as cool as they are now and resources were limited. Our agenda was simple, we wanted to get our product done at the lowest price so we could get the word out and see how people would accept the idea. After an unsuccessful attempt at finding a tech co-founder, I figured that outsourcing works much better than getting two or three full-time employees on a monthly salary, as outsourcing allowed me to get a quote for the entire project.


Image: shutterstock

Choosing a Vendor: I asked around, found a few development companies and fixed up meetings. I came up with a first draft of the requirement document, two or three UI reference styles for the meetings, and invited proposals. A few companies, who I thought were very professional in their dealings didn't give me an overall quote; instead they gave me a per hour rate and it wasn't going to work for me. So, I shortlisted the ones that gave me a complete quote for the project and finally went with the one company that came with the most recommendations, offered one of the cheapest quotes, and had recently completed a matrimonial website for a local vendor.

Multitasking: I wanted control over the design aspect. So my terms were that I would get them the design (psd files) and the rest was up to the dev team to finish. This reflected in the quote and the agreement as well. I found a designer and spent every day for the next month in discussions to come up with a logo and a homepage. By then, the dev company had already started working on the back-end design and administration.

Uncertainties: The inevitable happened. Things started going wrong - the project that was supposed to take three-and-a-half months, took almost 12 months and it was nowhere near complete.

Lost Time: The designs we gave to the dev team took ages to get past the HTML conversion stage, as the dev team had not worked on the design we had given earlier. The fields and the way our site worked were also new to them, which meant that they had to do some unlearning. This slowed down the work even further. Had they told us this concern at the beginning, we could have worked things out better.

Identifying a full-time talent: The head of the dev team was an honest and affable guy who was also very skilled. Unfortunately, he wasn't able to spend enough time overseeing our project as he had a full-time job. As our situation delayed, things at his other job changed and he needed to put longer hours there. I learnt that it's important to find one talented guy in the outsourcing team and make sure his commitment is full-time.

Lack of an eye for design: The dev team did not have a designer/UX person in their company, and the developers didn't bother much with our designs except for mechanically converting them into HTML files. It finally reached a point where after every iteration, the buttons on each page were of different sizes, the fonts were different across the site in addition to multiple other discrepancies.

Going with the flow: We decided to call the whole thing off with this company and launched a 70 per cent complete product to the market to see how people reacted. Our contract also stated that the dev team pay a small amount of money per day for late delivery. Since we had a few months of delay, we had started making money even before the product was ready, although it was a small sum. Having this clause in the contract made a difference as I could see the dev team and their stakeholders were really trying to get things done soon. The good thing is that we parted ways on good terms.

Facing Roadblocks: People loved the idea, but the feedback we got complained about poor implementation. I think we had 40 or 50 registrations just from word of mouth and a couple of focus groups. On the branding side, I had already discontinued working with the ad agency I had started working with as they were not bringing anything to the table. Unfortunately, they were the only ones we could afford out of the 10 or 12 agencies I had spoken to. Many of them didn't even understand the concept of Self Arranged Marriages and others were just too expensive. So now having no advertising agency and no dev agency (they were still fixing some issues), and not satisfied with the product, we were in a soup.

Way forward: Instead of giving up, I broke the tasks down, I started picking things up and piecing them together. My plan was to first get my act together with branding. We were all over the place. Being a 'cool matrimonial network', we had tons of ideas and one of the craziest was having the photo of a masala dosa on the homepage of a matrimonial site!! The product and UI needed to be improved to go to market. Luckily, I found these very talented women running a branding design company and worked with them to get the logo and full revamp of the website. In the meantime, I found a temporary solution, and got a dev team to finish the work the previous company had started along with the new design changes. This time I divided the task; I got the designer to create designs, another tech person to convert them to HTML and the dev team had to integrate them. This was of course a temporary solution.

Risks pay off: The temporary dev company managed to get things done. They were charging a fixed amount every month and I could manage that. However, they lacked enough expertise when it came to scaling, speed or complex JS conflicts. I had to ask for favors, find experts/friends who had to work with them to troubleshoot issues or bugs and standardise the code.

Thinking long term: In the meantime, I was hunting for a permanent solution – a dev company that would meet our needs. I found one, and we started working with them. This time, it was a recommendation from a professional contact. The owner, who was also working full-time with the dev team, was an expert. So he understood my concerns and the problems we had faced before and started building things slowly.

Foresight is important: We went live on Feb 15, 2015 [with the temporary dev company] and had a tremendous response. We had 1,500 registered users in the first two months itself. I was worried that if we were not able to bring up our new website, we would have crashes and poor page loads and overall bad performance from the site, which I really wasn't looking forward to. Being a startup, the adage, 'Customer is king' holds very true for us. Our work with the new dev team was going well and we had also started working on an Android app.

When the time is right, things fall in place: With the third and final dev company, we were able to keep the schedule, prioritise things (which we had done earlier as well but unsuccessfully) and track progress in real time. We moved very close to the iterative agile model, and we launched an improved product by end of October 2015. As of today, we have paying customers and we are in the early revenue stage with more than 4,200 registered users.

After thoughts: I'd like to sum it up by saying that every approach has its pros and cons. Outsourcing works provided you have the right vendor. My advice to you is to try and minimise moving objects between requirements, design, and implementation, and you should have a seamless product.

About the Author:

Saneesh Sukumaran is the founder of Wedeterna.in -Self Self Arranged Marriages. He grew up in Kerala's rich cultural heritage, after bachelors in Engineering, he traveled to many countries and have lived  in cities like Los Angeles, Boston, Delaware, Bangalore, Cochin, Prague and Singapore.  He likes to travel and considers himself as a people photographer. He is based out of Bangalore and runs Wedeterna.in with a small team.

More of my experience on LinkedIn profile

Website : www.wedeterna.in

(Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views of YourStory.)