Evolution of a Technology Startup

During the grunt times in a startup we mostly miss out on finer core details. We mostly end up weighing "new feature" against "needed feature". While this trade offs are a part of life, we must consciously draw a line. Some of my findings here are my learnings with Sokrati. Most of these are obvious but I am stating them regardless for completeness. Ofcourse this isn't complete and you may find me adding or editing.

Phase 1: Kick off
It starts when a couple of folks have already figured that an idea needs materialization and are now putting some code underneath it to get it out in the open. Most of the times we meet up next to a white board penning down our thoughts for action. The first thing to always keep in mind is carry a cellphone that has a camera and actively take pics of what ever you scribble down on the board. I found it time and again helpful to refer those pics to figure our what did we think then.

This is also the time that you need to have a version control system. I have used subversion extensively throughout. It has been pretty easy on me and has at times saved me a lot of hassle. Though you may be the only developer you would still like to maintain a version control on the same. You never know when you would wanna refer to what have you done before. It needn't be comprehensive or a kick-ass system, it just needs to get the job done. So when you enter "svn commit" you know you have it stashed up at some place.


Phase 2: Active development

Now you have switched on to the next gear where you have a couple of more folks working with you and your code base is gradually growing. The previous version control system would now make your life easier as you are collaborating in code. But since you have now churned out a chunk code you would be in a pickle if you the entire repository. Take the time now to write a cron that writes the source code to a persistent drive or maintains a backup. It can be as simple as getting an external drive which is different from the hard-drive where your repository is maintained. Copy over the source to the external hard-drive once a day.

Collaborative documentation may be another useful tool at this time. Media-wiki comes as a standard installation on any OS. It lets you store those basic information on "how to run make" or "where are my mysql instances located". It could also help you write a couple of "new hire" steps to ease the induction process for the new person joining. You could state here your coding practices which become more important as the code-base becomes bigger and unmanageable.

If your team is working remotely i.e. working from their homes most of the time then you need to provide an entry point to your wiki and svn for access. You could use Dynamic DNS for that and open up a couple of ports on your router enabling connection to your server.

At this stage thinking through extensively regarding security i.e. wiki access or svn access might be an overkill. But yes opening up a port on your router has its hassles too. So safeguard your access with a basic user/password known to only a selected few.

Code reviews is one necessary element of any software cycle. Take the time here to come up with a good methodology for code-review. I use a ruby script that converts "svn diff" to html and I save this file which I later send it out for review. Others have started webservers on their hosts and they copy the htmldiff of their review in a specific directory and send links out for review.


Phase 3: Starting out to get some business

You would now have a website, a registered company, bank accounts etc. You could use Gmail's free Google Apps to manage your company email. I also found it useful here to be able create spreadsheets that can be shared across your team.

Your website could easily be given out to an e-lancer, who would do a good job for about $300. You could also tinker with Jhoomla at this time. Though with limited resources I would vouch for concentrating on the core business and letting someone else bring the expertise of bringing the site up.

You now also have the burden of hosting. I have worked on Amazon EC2 exclusively. The ease of deployment and launching is unmatched. I have tried shared hosting with GoDaddy but I am pretty restricted with the software provided or the nature of accessing is very unintuitive to me.


Phase 4: Got some clients now

If you have a garnered some clients that means you are in production now. While you so far carefully nurtured your systems and have been paying close attention to them, you may now realize it is becoming hard to keep a close eye. Any software failure or system downtime needs to be tracked else you may have an irate client, who got pissed off even before he could see the meat of what you had to offer. So track your production hardware closely, atleast monitor your system uptime using pingdom.com etc, which will atleast let you know when your site goes down.

If you wanna brave the odds and integrate deeply into your production hardware you should try out Nagios. This is an open source monitoring system that lets you ping your systems periodically. You need a nagios server which can do most of the monitoring from the server itself. You need to open up a port + install NRPE plugins your client boxes for monitoring. You can also develop cool plugin scripts if you need additional functionality. Nagios emails a notification upon any failures. If you need instant notification on high-severity issues like "host went down" you could write a script that apart from emailing would also send you an SMS. There are some SMS gateway providers in India which are free like way2sms, sms gupshup or paid services beep7 (which I currently use).

You may also wanna start tracking features + prioritizing features. You could use TRAC for that and I have also heard Pivotal works well here. I have integrated NAGIOS into trac which cuts a ticket to monitor notifications.


Phase 5: Got some traction

Traction could mean the growth in clients or growth in software or growth in the number of people working on your product.

Here is where things get murky. While you are trying hard to keep churning out new features you would realize a part of development is still very adhoc and uncertain. And I strongly believe at this time pick a resource out and work on a few things which would improve your software development.

Tool to browse source code online. This helps at times for you to be able to send out emails detailing specific code-snippets with exact line number etc. I have integrated SVN with TRAC here that helps in navigating the source code.

Continuous Build System such as hudson which smoothly integrates with SVN is extremely useful to detect build failures and to maintain a code release methodology. I maintain release branch for each deployable software along with mainline (used for active development). Hudson detects any new changes in any branch and automatically issues a build. It also provides plugins to run automated tests.

Issuing a support mechanism for clients to flag issues. It should be simple enough for clients to shoot an email out and that gets registered as a ticket which is being looked at by support. Here again TRAC played helpful to us. We put in a plugin that takes emails (email2trac) and converts them into trac tickets. These tickets are monitored on a priority basis and handled without loss of information. I have also heard good things about OTRS www.otrs.org here.