5 points to remember while coding for a startup project

When you plan to code up an application for a start up, the best part is there will be a lot of excitement. What you build may be a trendsetter or a game changer. The thought itself is motivating and elevates the energy level. It opens up a lot of possibilities and a chance to explore and learn new areas.

Well that's the good part of it. And there will be an other side too to it.This assignment can be a lot more challenging than a normal project. Implementing a startup solution needs much more discipline and planning because of factors like time, lack of direction, budget and frequent iterations and pivots.

Here is a summary of my thoughts on the essential guidelines for a developer on a startup project  based on my experience with the technology and application development for startup.

1. Understand the business and primary goals.

This is an important factor on any kind of project. But in the case of startups this is much more important as there is narrow tolerance for mistakes. As a developer, you need to try  and understand the business and purpose of the application very well and the goal it is trying to serve. This helps in  setting priority while working on different components of the app. The data mining algorithm for an analytic tool is much more important than adding bells and whistles in its user profile section.

Also understanding the purpose helps in creating better test scenarios that will help in critical validation of the project.

2. Plan for quick releases and agile development.

There will be a conventional SDLC model with every organisation. The development team also will always tend to stick with it as it keeps them in there comfort zone. But a start up application demands much more agility. There will be an MVP stage mostly before the entire project completion and there will be many subsequent release cycles before the development is complete.  Some areas need to be re-coded and the UI's need to be redone based on beta customer feedback. Sometimes a total new functionality need to be implemented in a matter of days.This might not be an ideal scenario for a developer.

Well, there is no point in complaining about it.Accept it. Agility is part and parcel of startup projects. Only possible solution is to plan it as much as you can. Keep hooks in the code for change.  Keep a stand by resource in backup to manage the need to slog and be ready to scrap a portion of your hard worked module if the business side demands so.

3. Minimize experiments with the language.

Consider that you are an expert in LAMP or ROR and you are planning to expand your skill in NodeJS ( as it is the hot keyword among web developer community now). Your plan in most cases will be to code a portion of the next project if not all in Node. Considering the capabilities of node, it might not be a bad decision as well. But if the next project happen to be an advanced startup application my suggestion is to save your plans for next project after this and select the LAMP stack, in which you are a rockstar, for this project. The new language reduces your speed and efficiency as there is a learning curve. There is chance to make mistakes in method and implementation as you are still a beginner with the new technology. Both these factors may turn out to be critical blows for the project which cannot afford many. 

4. Code less but clean and reuse more.

The MVP' s are not meant to be complete functionally. Beta releases can afford a few unfinished areas if primary flow is working. The critical factor is time and cost vs effort. So for startup projects it is always important to identify key areas and spend effort based on this. You can keep stubs for some logics which can be coded up later. The optimized logic for handling a lakh concurrent  users  can be implemented later once the user base increases, if it takes a lot of time and effort. Think what need to be done in later stages and leave hooks for it and proceed.

 At the same time it is important to keep the code clean, manageable, reusable and structured. There may be a lot of change in subsequent phases which will be a pain to accommodate if the code base is too rigid. If there is enough generalization in the core entities and logics, new features can be inserted in like a knife in butter. 

5. Keep the system light and flexible.

Implement the minimum essential logics in the early stages while on startup projects. Expect pivots in requirements and plan accordingly. Those areas which are not functionally scoped out completely or has a higher chance for modification can be kept at the back of the priority queue or can be done in a minimal way avoiding fine tuning and optimization. 

Well, these are only few of the considerations. There can be much more. If you have a few suggestions share it too.