Since my seven years of working life I have spent 90% of my time working for start-ups, so here I am describing my experience so far and also putting in my own opinion regarding the issues, it might differ from yours but this opinion is solely mine, you don’t need to be agreed upon with me, if you don’t buy into stuffs I said here, never mind just move on, I will be glad thinking that you spent some of your precious time reading this post. By the way this is a long post so I recommend you to have a cup of coffee or some light drinks with you while you are reading this post .

The three things that I would like to touch upon in this blog post are below:

1. Planning and proper understanding of what to build.
2. Technology and architecture
3. Employee management

In India start-up software companies begin with a very novel idea and most of them are novel indeed, but the number of ideas we have and the number of successful results we get at the end of the day differ a lot. So what are the problems why so many start-ups fail miserably, what are the common mistakes they all make, and how they suffer? To find answer for each of these questions one needs to carefully analyze all the efforts that have been made in order to make that idea a real thing, often we see that entrepreneurs talk about a certain idea which they think is something big and has the potential to change the world, but in reality most of the time those ideas are based on limited market research, inadequate domain knowledge and a lack of practicality which includes very limited understanding of users’ need. Here I am trying to express my views regarding the points mentioned above that any would be entrepreneur should be careful about, because these are the things that matter most if you are in a high-tech industry, which is distinct in every essence than other industries. Innovative idea with proper approach is what makes you stand out among the crowd at the end of the day.

Planning and proper understanding of what to build

In start-ups the actual planning started in most of the cases with some ideas and a limited discussion around it, in rare cases it’s being documented, the discussion happens around how many screens are there, who is going to do what and how quickly we can build, if you are in a real hurry and want to earn huge money as quickly as possible then you probably are not a true entrepreneur or you are one of those greedy people to whom only money matters, remember there’s no shortcut to glory, you got to work hard.

Engineering your dream is not just bringing a US bound guy on board without judging his technical capabilities, that whether his expertise aligns with your vision properly or not, you really need a very technical person with a lot of domain expertise in building stuffs that you want, who will work as your advisor and also as one of your trusted partners while building your dream. You need a real engineer in this case.

Research is to see what everybody else has seen, and to think what nobody else has thought – Albert Gyorgyi

I think when you are out to build a start-up, you need to do a good amount of research about your target market, yes I mean it, and it’s a serious thing. You need to do proper analysis. I sometimes wonder that how someone can start building products without analyzing the market, you need to be sure and backed up with statistics that indeed there’s a need for your product, don’t just read some articles and start assuming that there’s a big potentially huge untapped market for your product, watch your steps dude!. A good approach can be to identify some of your target users, engage with them, get their feedback on the problem that you are trying to solve, give them multiple solutions, see which one suits them well. Start with your market before building your product. Try creating product documentation, PowerPoint presentation, and prototypes (it’s a must), get a clear understanding of what you are trying to build, bring your vision into reality slowly and steadily, I know entrepreneurs don’t like the word ‘slow’ but remember “Slow and steady always wins the race”. Having a prototype before you build the actual product is pretty important because it can help you see that how people will interact or use your product, if you don’t find the prototype compelling enough for yourself then think again before investing your fortune.

When you are out to achieve your dream, you should keep in mind that most of the time you have limited resources, so precise planning and careful usage of your resources can yield you pretty satisfactory results, and the most important of all is to have a clear understanding of your goal, and a path to that. “Rome wasn’t built in a day” – so plan an incremental program, be realistic that how much you want to achieve in a certain version, then further break it in multiple iterations, remember the more impatient you are the more the chances to make mistakes which will eventually wash out your dream. Don’t build everything that you have in your mind, instead carefully decide the set of core features, which often is a small set of necessary features, keep them modular so that you can easily pull them in or out, have a good amount of discussion around core features, keep it small and extensible, build the base first. So once you have the first version ready, gather as much user input as you can, ask your friends or anyone outside your company who is not associated with the idea to evaluate your product, consider their inputs because they are the people who are going to use it at the end of the day, incorporate their inputs, keep this practice going until you reach a stable version. Avoid having “too many features”, yes I mean it, having too many features actually confuses the user, so don’t give your users too many choices, don’t even expect them to remember how to use each and every feature that you provide, so having a small set of useful features is good in this case, don’t waste your time building on a lot of features, control your temptation to add as many features as you can or you think can be useful, don’t assume unless you really have the statistics to back you up that those features are indeed necessary. It sounds a cool thing that your application has multitude of features than others, I have seen entrepreneurs brag about it that they have tons of features that their nearest successful competitor doesn’t have, this does not make sense if only 1% of your users are actually using those features. So remember having tons of features won’t help, even if you think you want to have those then build your application like a platform and allow others to build the missing bits on top of it.

Lastly, I would like to say that don’t just copy what others have built, remember copying won’t help, for example if you copy Facebook or Twitter and thus assume that your application will be a great success, then you are simply ignorant, or just don’t understand how web works. It’s like selling a car which has its engine from Ferarri, chassis from Honda and other accessories from different vendors and you think that you have built a great car and people will buy it like crazy, nobody will because it lacks originality.

Technology and architecture

The technology defines a product; it is the underlying system which works to make sure that a user of the system performs his desired tasks gracefully without much hassle. The aim of the system should be to aid the user to achieve his target, it should not come into the way of users to do their stuffs, a system should be designed to make a complicated task simple, and it’s of no use if the system itself makes a simple task even more complicated instead of doing the other way round. When designing a scalable architecture you should keep in mind that modularity is your way to go, there should be a clear separation of the parts which makes up the system as a whole, this greatly reduces the maintenance hazards in long term. I understand that when you are building a system there will indeed be dependencies, but there are lots of cool ways you can handle it, read DI (Dependency Injection) or consider picking up “Design Patterns – Elements of Reusable of Object Oriented Software”.

Choosing the right architecture is equally important while designing the system, a wrong choice can put you in big pain at the beginning and a careful consideration regarding the right technology will save you a lot of dreadful nights. Consider a matured Open Source technology backed up by a vibrant community.

Another thing regarding designing the architecture, remember it is not just designing the Database only and if you think database normalization is the only thing then this is the first sign that you are going to be in deep shit sooner than later. The whole architecture depends on the application design, modularity and extensibility, if a system was not designed to be extensible then it’s doomed to be a failure. I have noticed some conceptual problems where people think that the scalability and stability of the system depends mostly on hardware than on software, they think that the more hardware you have the more faster your system will be, which is just as wrong as to think JavaScript is a subset of Java. If your system was designed to be modular then you can plan for better QA, don’t try to finish things as quickly as possible which often results in error and reimplementation of the same, some people try putting more resources to finish things quickly, remember one simple example – “it takes 10 months to have a child, if you put 10 men or women, that does not mean that you can have a child in one month ”. Have a proper review process, reviewing and thus maintaining quality is very important for a system to evolve, and a serious introspection can often find a lot of errors even before writing a single test case.

If you are building a web application, you must have a browser support chart in place while designing the system, if you don’t have one then it is a sheer example of improper planning and a recipe for the disaster. One of the pain-points in modern web development is supporting IE6, do a little upfront research regarding your target users browsing environment, if you think you need to support IE6 then plan accordingly, but please don’t change course in the middle, don’t just decide to start supporting IE6 in one fine morning, you should consider doing the cost benefit study before supporting IE6, if that suits your financial model then go for it else decide upfront what to do. One option that you can follow is “Progressive Enhancement”.

Last but not the least, if you are using some well-established open technologies there you may find some way to customize it, then keep the customization as minimum as possible, never try to use the ability to customize as a tool to change the behaviour of the open system, don’t just unnecessarily add proprietary extensions to it, if you can’t make it work properly, then do a research that how others have done it and what’s wrong in your approach. I have this experience before where I have seen people changing XMPP protocol in such way by adding lots of proprietary extensions to it and that it has eventually become a massive pile of shit and it can no longer be called XMPP and the funny thing is that if you implement XMPP it is normally assumed that the existing XMPP clients can communicate with your system, but in the above mentioned case that system actually broke that compatibility, so the lesson is just don’t do that. Remember what the Zen of Python says “There should be one– and preferably only one –obvious way to do it.”

Finally a bit about Application Security, when you are building a system which will store user’s personal data then you must make sure that your system is secure, remember security is an important thing, because users trust your website that you will respect their privacy. Ask your programmers what they know about security, you might be disappointed that how little they know but tell them to learn the best practices. Don’t implement “Security using obscurity”, this does not work. Make sure that your system does not have any “SQL injection” hole, if it’s a web application consider preventing XSS, Session/JS Hijacking scenarios, another example if you are using Flash crossdomain.xml, beware that this can expose your website to variety of attacks.

Engineering is not making a perfect solution, but doing the best you can with limited resources – Randy Pausch.

That’s it regarding technology and architecture, a robust application design can benefit you from lot of ways, so take your time to design, do proper research prior to it, hire right people and carefully use your resources.

Employee Management

This one is a bit tricky, I wanted to avoid talking about it but without this it looks like incomplete, so let’s read on. In start-up companies initially you will see people digging into technologies, learning new things, trying to do stuffs that they always wanted to do, almost half of them are the right set of people that you need, not everybody wants to work for a start-up by the way and those who work have at least the mindset to work for a start-up, so keeping those people motivated and nurturing them is the only way to build a start-up workforce as I think. Start-ups are known for “Open Environment”, “Flat Organizational Structure”, which is very crucial for the growth, and this structure needs to be maintained all along till your company is a start-up. Don’t try to bring hierarchy in your “twenty” people company, geeks often find hierarchy very annoying.

Let the programmer be many and the managers few — then all will be productive – Tao of Programming (http://www.textfiles.com/100/taoprogram.pro)

People usually work hard in start-ups and they deserve recognition for that, so if you see that people are working hard for you then encourage them and give them the recognition that they deserve, don’t just piss them off saying that you stay late in the office so it means you can’t finish your tasks in time, which is in reality a big lie and enough to demotivate that person. Treat your employees properly and if you hire someone then give him some time to get used to the system, plan for some sort of training for new joinees. I saw once that my company hired a young fresher in my team(without discussing with me) and gave him an HTML book to read and the very next day assigned him some bugs to solve, then I had a talk with that guy and learnt that he never had done HTML in his entire life and he then needed to solve those bugs, this incident just made me surprised, this isn’t the way to treat your employees, I saw a lot of dreams into his eyes but I knew that some of them are going to be crashed because he landed up in a wrong place for the very first time in his career, I feel bad for him, so my advice to those entrepreneurs who do this kind of stuffs that don’t just break the dreams that people have think that you have created a start-up to achieve your dream similarly others do have their own dreams, don’t break them, if you can’t help then don’t hire, don’t be a jerk. Here is a small solution that I have come up with if you have freshers working in your company and don’t know whether they are improving or not, then ask them every month that what are the new things that they have learnt in last month, verify their answers, this will make them learn new things, which in turn is a good thing. Plan some sort of tech talks every two weeks, which will create an environment of sharing knowledge. Lastly, the psychological well-being of the employees is very much important for the company’s work culture and long term benefit, forcing them to work hard late night will soon burn them out, which results in quitting, exploitation can’t work for longer period of time, entrepreneurs should understand this.

Okay, that’s it; it has become a long post, if you have come to this very last paragraph then I personally thank you for your patience and the time you took to read this post. All the above things are my thoughts and here in this blog I like to share the stuffs that matter to me. If you think that my concerns are valid ones then I’ll appreciate if you comment, by the way it’s not necessary. Finally, this post was not intended to hurt anyone; I tried to keep it as constructive as possible, with bits of my own experience as examples. I hope you have enjoyed this. Thanks for reading through this once again.