[Editorial notes : Even though you are a non-technical founder, it’s important that you understand technology and nuances of development, as it gives you a better picture and understanding. Guest post by Sarvesh Agrawal of Internshala brings some fresh perspective.]
I started Internshala as a part-time gig and as a WordPress blog in Dec’10 – after initial traction and validation, when I decided to pursue it full time and to convert it into a fully functional portal, I had expected the task to take couple of interns (along with a part time CTO) and at most 3 months – this was summer of 2011. We finally went live with Internshala 2.0 (what was originally meant to be Internshala 1.0) in October 2013 – a time over run of 8X and cost over run of 12X.
Partly because I was naive; and largely because it is (cliche alert!) really difficult to find good technical talent (Good = Skill+Will) to work for a start up. I feel fortunate because not many (or any?) start ups can survive this sort of time and cost over run.
There have been a few good lessons that we learned during this incredibly long journey that we may not have learned if not for this delay.
1. As an entrepreneur, my job is to solve a customer’s problem, and not to build a cool product – this is not to say that having a great product (i.e our current website) does not help (it is a BIG help actually and we are just beginning to see the benefits) but for a large part, there are enough solutions available online (we started with a WordPress blog and added lot of plug ins, google forms, a bit of coding to put our initial product together) that one can use to start solving the problem and find initial traction.
2. In India, one can win basis great service alone/also – For last 2 years, Internshala had the most basic of the website among all the players in internship space and still we became the largest – thanks largely to the prompt service we deliver to employers and students.
3. As a founder you must get your hands dirty with the code – I used to be scared of programming back in college but not having a full time CTO in the beginning and no CTO afterwards, forced me to learn the basics of web technologies. This helped a lot where I could self manage the day to day technical operations while allowing the scarce tech talent in the team to focus on development. It also helped me become a better product tester and tune into and contribute to discussions with the technology team. I also think the technical folks in the team would respect you a little more just because of your technical know-how and because you can understand and speak their language.
4. Launch light – I can count ‘n’ number of features I had originally asked for which the team spent at least 6 months developing and finally we launched without them. In hindsight, we should have started with a very basic version (delta improvement over existing WordPress set up) but with a modular and scalable architecture to allow features to be built later on. In absence of that clarity, by the time technology team finished developing a set of features, the business requirements had changed.
5. It’s incredibly hard – and takes longer than you had thought and more money than you would have. There are far too many variables for one to be able to plan. But you are not alone (if that is any consolation) and you need to have faith. We got lucky 4th time (a part time CTO + 2 interns + part time free lancer, a fully outsourced model, and a fully interns based model were first 3 attempts) and it was pure luck that 4th time we were able to find Ungineering (a startup that was inspired by Internshala and now manages technology for us) and hire a great developer internally at the same time and gel the two to get it done!
6. Variable (per hour) cost model works better than lump sum – Only if you could find a trustworthy IT partner to outsource the project to (in absence of an in-house team) which fortunately, we could. Since the requirements are so fluid, it just helps iterate without any hard feelings. Also, in my experience, the developers are not necessarily great at negotiating timelines or project planning and have very little control over how much time a particular feature might take. Be extremely cautious in deciding whom you pick for the job, but once you have picked someone – trust them.
7. (If you can) Insist on development to happen at your premises – Even with Ungineering, project picked up great pace when Anuj (founder of Ungineering) decided to move to Gurgaon for couple of months to work with Varun (in-house developer) to finish the project. Despite all the technological advancements which allow for remote development, the communication lines are clearer and decisions get taken faster and a sense of belonging develops when people work under the same roof.
8. And finally, there is a plus side to this delay too –
a) For first 2 years, a very modest appearance of the website helped keep the expectations low among first time users whom we pleasantly surprised with our reach and service and they became fans.
b) We learned a LOT about the market and user behavior during these 2 years that we did not know earlier. This knowledge helped us build few features that are actually useful for our users and cut down on few others (for ex. Facebook connect) that were just good to have.
I hope this helps others who may be in the same boat I was during last 2 years. And those who faced and overcame similar challenges in the past, I would love to hear about your experiences.
Recommended Read : So You Want to Code? Essentials Skills To Become A Great Programmer
Pi of Life : The Value of Doing Things with Your Own Hands