IT Strategy for a Web Startup
As we near the completion of a major web application for a startup, it's time to reflect on the factors responsible for the success.
- Cloud Computing. The hardware cost for development was less than $750 including the cost of a laptop.
- We used Google App Engine for the most part but not exclusively.
- For confidential documents, we used Amazon S3, preferring to go directly between the browser and Amazon, bypassing Google. Any doubts about whether Google will mine those documents were neutralized.
- Staying conceptual with the implementation.
- Google App Engine was great for helping us stay conceptual. They take care of scalability, backups, OS versions, patches. All the stuff that drags you down.
- Amazon EC2 is too low level. One has to worry about scalability, backups, OS versions, patches. We should have gone up a level by using a service like Rightscale. We haven't yet, but it's still an idea worth pursuing.
- For the same reason, we would consider Amazon RDS over doing our own database management.
- Open Source Software. Most notably, jQuery. Their slogan is "write less, do more". The reality matches the slogan. A rich milieu of available software allowed us to assemble components rather than write code. A couple of times we were bitten by it too. A month after we had integrated a component, the developer decided not to support it any more. We switched away. So one has to stay agile but that's the name of the game anyway.
- Staying conceptual with the requirements. This was the second-biggest factor: working with a team that trusts you, things don't need to be written down to an excruciating level of detail. You hear the requirement in vague terms, you implement it, and if you had misunderstood, well, change quickly. Keeping the Agile Manifesto in mind.
- Tracking shifts in business strategy. This was the biggest factor. The business strategy changed at least a couple of times during the project. The development was continuous, however. We were surprised to discover that the changes forced us to re-factor the code as it was re-purposed to fit the changing strategy — but very little of the code was thrown away. The re-factoring may have made it more modular, actually. By the time the business strategy had settled, we had software components that were well-tested already. Only the final integration was left to do.