The GSF Accelerator is a 7-week program designed to foster innovation in India’s fast-growing digital economy. It aims to provide select, promising start-ups in the mobile, social, local and cloud spaces with unparalleled access to venture and business networks, personalized and intensive mentoring, and initial capital. Coaching will be provided to each of the 12 GSF startups over a period of seven weeks by a mentor pool of over 200 cofounders and digital entrepreneurs from across the world, who are part of GSF Accelerator. This article is a part of the series of the mentorship sessions held for the startups.
This mentorship session focused on selecting technology frameworks and building scalable applications. The contributing speakers were Ram Singla (Zomato), Gajinder Singh (PayU India) and Amit Sharma (Khojguru) and discussed on how a development cycle should look like, discussed below.
Find the core value propositions first – for example, whether the mobile payment app or the hardware POS device is the core or whether local content aggregation or sentiment analysis is the core. And it isn’t constant. It changes, it evolves.
You need to find all the options that are available to you for the technologies that you would be using, and rate them on factors like time to market, enterprise, availability and cost, roadmap, legacy code, prior experience and learning curve.
Development – “Ship soon, get feedback, iterate often.”
The development cycle goes from requirement to development to testing to review and finally releasing it. Then you take feedback from the user, fix bugs, add enhancements and release back – it happens again and again. Get it out, experiment fast, fail fast. You should simplify the application from the perspective of the user and time to market. Also, don’t be dependent on one platform. Use open source platforms if you’re well versed with them.
Don’t overbuild – “Find the mojo – where the sweet spot lies.”
You should focus on building what you need today, not years down the line. If you would be guessing, you’d only increasing maintenance burden.
Explode – “Decouple as many things as you can.”
When you’re going to grow huge, you’d explode. You would need to have independent components, API driven interactions, separate application logic, and even need to cache like crazy.
You should know the flow of your program and be able to pinpoint a leak – can you get rid of the leak? How? Can throwing more hardware help/delay the problem? You need to engineer the bottlenecks – know the exact scenarios and how will they evolve by looking at the current ecosystem – for instance choosing between fingerprint or QR code.
Plus, you should always be logging data, even if you’re not using or analysing it. It would help you in the future – for instance to determine user’s preferences, etc.
Don’t tend to solve long-term problems, have a 6-month roadmap.
Do it fast, push it out, let the customers give feedback. Anticipate what they would want next.
Keep is simple.
Be frugal, don’t waste money.
Scalability: throw more hardware at it if it helps.
Run the company on data that you collect.
Again and again.