My Experiences with Outsourcing and Inhouse development of tech products

Disclaimer: YMMV (Your Mileage May Vary)

The last seven years have seen an explosion in tech-based startups. People find a genuine problem to solve, take the startup plunge, and set out to build a tech platform (web-based or mobile-based) to execute on their idea. Those that are non-technical set out to find a CTO to help them build the app. But this has not stopped many from taking decisions to get the app development started. But a key struggle here is –

“should I outsource the development and then bring it inhouse, or should I build it inhouse right from the start?”

I was on a #techadvisory call this morning where a non-technical founder posed the same question to me. I reflected back on my experience at Clearfunds, where we had outsourced the tech development to a vendor in Bengaluru with the ultimate goal to inhouse the platform, and my current experiences at Glide Invest, where I am building the platform inhouse from scratch. Both have their pros and cons, but I thought this would be a great opportunity to share my learnings from these two different situations.

Pros of Outsourcing …

• faster speed to market: That’s a given, especially if you are a non-technical founder. Working with a ready-made team will enable you to launch quickly.
• access to experience: you don’t have to search for designers, developers and testers who have experience building similar platforms. Many of your tech complexities will be taken care of.
• no recruiting headaches: Recruiting is a bitch, and your vendor will be responsible for managing upscaling, downscaling and attrition in the team allocated to you.

Believe it or not, Slack was designed and built by an outside agency!

… and its Cons

• selecting the right vendor: assuming you find 3 vendors who have built equivalent platforms, what’s your selection criteria for your vendor — estimated project cost or technology that they are experts in? And don’t fall for them saying “we are not your vendor but your partner” — that’s humbug (unless you tag them to all bugs raised by customers — both internal and external)!
• dependence on vendor for technology: while the final technology stack will be jointly decided by you and your vendor, you need to keep close watch and control over long term maintainability and viability for you. Your vendor makes money by doing less for more. So they have little incentive to use the best versus what they know. When you eventually want to insource the development, are resources for those technologies going to be easily available? At Clearfunds, our technology was built on Ruby on Rails, but finding Ruby developers in Mumbai was very difficult, especially after some Mumbai based startups moved their Ruby-based teams to Bengaluru.
• focus on speed vs quality: vendors are focused on delivering the product faster and cheaper for them. One critical aspect that gets ignored here is code documentation. Developers are too lazy to add inline documentation, and are not required to by their team leads. At Clearfunds, our vendor gave an additional 2 months full-time estimate for documentation alone, inspite of the fact that documentation was part of their scope of work. And code documentation is essential, especially if you finally want to inhouse the code, or if someone new joins the team. Additionally, given that your meter is running, there is never time and budget to resolve #technicalDebt in your code.
• no guarantee on team continuity: nobody in your vendor’s team is indispensable. So what happens when the top developer on your vendor’s team goes to their manager and tells them they are bored of your project and want to work on a new project with a new technology. At Clearfunds, our vendor came crying to us with the same sob story with a promise to fill the gap. And just like that, we lost your top developer, and had to pay for a junior to understand our entire product logic and code base. And that cost too had to be fully borne by us.
• its more expensive in the long run: outsourced models are always more expensive, since you are paying for the overhead cost of the company through what is called a blended cost of each resource. Plus there is little quality check from your end. At Glide Invest, we interviewed and rejected a candidate, who wanted an in-hand salary of Rs. 30K/month. The same caliber of candidate would have cost you Rs. 50K/month + 18% GST if sourced through a vendor.

Pros of building Inhouse …

• better control over application development and tech stack: your CTO/Tech Lead can take the right decisions on what technology to use, based on the availability of resources, talent, and technology expertise. They can also experiment with new technologies where required and pull back wherever required.
• more control on quality: you can set a culture of coding standards, code quality, use of linters and documentation right from the beginning. This is very essential for continuity and also getting new joinees to read and learn the logic and pickup the code on their own, without too much of supervision.
• higher flexibility in making changes: your team is right there. Changing the scope, adding small enhancements, or changing the design and logic happens much faster with an inhouse team. Your PM can manage scope changes, but execution is way faster.
• fostering a culture of ownership: A must if you’re building a company, rather than just a product. #technicalDebt was only possible with the inhouse team.
• being taken seriously as a business: If you’re looking to raise funds from an investor, for a tech-driven platform, good luck winning their confidence if you don’t have the necessary in-house expertise — or a plan to bring that on board, as your initial MVP is developed.

… and its Cons

• no guarantee on team continuity: nobody in your team either is indispensable. Most junior to mid level developers stay for 18–24 months at a company before they get bored and leave. You need to keep your tech stack exciting enough, or hire with that timeline in mind, and be prepared to replace when this happens.
• building a tech team is tough: good tech recruiting can be a “make or break” part of building a successful platform. At Glide Invest, on an average, we typically go through 40+ resumes before we finalize a good candidate. But today, demand exceeds supply, and building a team is getting tougher and tougher. Tech recruiting in Covid times has become very competitive and challenging. Candidates don’t want to go through a long recruiting process anymore. Naukri is full of junk candidates. B.Sc IT is big farce — nobody learns anything in that degree, and MCA candidates are not significantly better. No startup wants to wait 3 months for candidates from MNCs to complete their notice period, which also equals 3 months more for candidates with an offer in hand to look around for better options, and NOT have to show up on the first day for you! And don’t ignore the culture you set within the team. IMHO, “Culture eats strategy for breakfast” stands very true for any business or team out there!
• slower product launch: and all the above cumulates into a slower timeline for launching your product. And this is by far the biggest tradeoff of inhouse development for me.

There is no perfect answer as to which approach to take. If you don’t have a technical co-founder / tech lead on your team, the former is probably a better route. If you have one, and you can survive a slightly longer launch time, then the latter may be better. Remember: YMMV!

So if you take the outsourced path, work towards mitigating the cons associated with it, so that you don’t burn out all your cash, don’t become totally dependent on the vendor, and setup your systems so that your team can eventually take it over. Put in the time and effort to execute solid contracts also, for you can do without contributing to the horror stories of tech consulting engagements gone sour.

You may be able to find a vendor who would architect your platform, deploy a project manager and a few engineers on it, with the understanding that they’d deliver not only the MVP but also let you absorb an engineer or two in-house, for continuity on the project. That was the approach adopted by my good friend Anil Kumar, who worked with a small, Chennai-based tech company in building the first version of Jodi365.com back in 2010. The code base and two engineers came on board in 2011. Of course, as the business grew, the matchmaking platform was re-built, on a vastly superior tech stack, under the supervision of an in-house tech lead, in 2015.

I hope you find this useful and relevant to your situation. Do share your comments below. And if you need any help with the decision making process, feel free to get in touch with me.