Engineering this website


In its nearly-4-year history, this website has had a rich history. In addition to the content changing, over that period it has incorporated (and later removed) eCommerce, polls and email-based workflows. 

Blogging has always been separate because the website was built on Google App Engine and I could not find a suitable blogging engine. I used Wordpress for blogging. But using a separate engine for blogging does not provide a smooth transition between the website and the blog. Integrating SEO between the two is not easy either.

This latest set of changes to the website takes the work of  Ivan De Marino, which was based on Nick Johnson't Bloggart, and integrates it into the website. 

Starting from Ivan's distribution, a few additional changes were necessary:
  • Additional pages, such as Contact Us, built using the standard helloworld pattern.
  • Conversion from Python 2.5 and Django 0.96 to Python 2.7 and Django 1.2.

The 7 signs of failure for internet startups


Blackbox has just launched their first Startup Genome Report. It's been getting quite a buzz in the community, including VentureBeat and Steve Blank's website. The report speaks for itself. If Max and Co. at Blackbox achieve half of what they have set out to do, it'll change the way investing and entrepreneurship gets done. I mention the report and the brouhaha accompanying it on this blog for two reasons:
  1. It tracks our experience well.
  2. It fits our business model: Early Stage IT is a partner to start-up teams and can bring your team that much needed technology focus, or add to it.

How to Get Professional Assistance When You Can’t Afford It


Some thoughts while preparing for  this panel discussion on Tuesday.

First, a little bit about Early Stage IT. We do IT for Early Stage companies. No, not installing machines type of stuff. More like IT strategy and execution, especially web applications. Our positioning is exactly in this space: startups. What attracts me to this space is that it's very dynamic, it attracts a lot of very smart people who are not only smart, but can get things done and make concepts come to life. We started a couple of years ago, and it took a while to get things going — a long dry spell in a lousy economy — but things have started to turn around, and I'm happy about that.

Let me talk first about a failure. It's kind of the right of passage in the startup world, right? We built this web site for helping High School seniors search and apply for scholarships. We built the web site on Google App Engine. I coded most of it, and we had a young woman helping out.

She had dropped out of the workplace about 6 years ago when her second child was born, and now that he ...

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.
  1. 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.
  2. 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.
  3. 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 ...

Structuring Software Development Relationships


The two parties in a new Software Development Relationship don't know each other, so what's the best way to structure their relationship?

We want the contract to be fair in distributing risk between the parties. We want to write the contract in such a way that neither side has an incentive to take advantage of the other. Finally, we want to write the rules of the game such that when things go awry, both sides have an incentive to fix the situation rather than descend into worse.

On the one hand, Early Stage IT does work for clients and that puts us in a "supplier" role. On the other hand, as virtual CIO for our clients, we play a "client" role vis-a-vis other suppliers. With both roles in mind, we did a survey of billing practices people employ. In this search, we favored billing practices that align with agile development. To cite some models: