Andy Kelk


Software as a Service at the turn of the millennium

This post was inspired by a discussion with a colleague about one of my first proper programming jobs which I started 14 years ago this month.

Back then, the tech world was reeling from the bursting of the Dot-com bubble which had well and truly popped. I had been working at my first proper job for a company that had ridden the wave and was coming back down to earth (that new HQ in Oakland, CA? Yeah, we won’t be needing that). One of my colleagues went off to join a startup based out of a top-floor office in London’s Soho Square. [it’s so hard to write that sentence without calling it “London’s trendy Soho Square”].

Boo Hoo

Apart from the fact that I felt spectacularly under-qualified to be the sole programmer other than the company’s CTO (I’d got through the interview based on some pretty scratchy knowledge of Perl and CPAN), I was thrilled to be part of something new and exciting. The company had picked up the assets of failed Dot-com horror story boo.com including one of the key technical staff. We were tasked with turning those assets into an eCommerce platform that we could provide as a subscription service to retailers.

Yes, that’s right, a subscription-based eCommerce platform, you don’t own it – you get the software as a… service. Back then, of course, we didn’t call it SaaS; we were an Application Service Provider (ASP). We started out with single tenant instances of the software which were customised for each client but quickly moved to a multi tenant model where a single core codebase was overlaid with plugins and themes.

Bleeding edge technology

The hosting started out as a single Windows box running ActivePerl on IIS which needed to be rebooted every day to keep it going; it rapidly grew to a farm of Linux machines running at Savvis backed up by postgresql. The app slowly (very slowly) matured from a ropey Perl codebase to a slightly less ropey Perl codebase. Source control when I started was a shared drive with a naming convention for each day’s copy of the code; we did “upgrade” to Visual SourceSafe – a product that only allowed one person to edit a file at a time. Imagine how blown away I was when I first used CVS at my next job.

I remember being asked what “methodology” we were using when visiting a client once. I had no idea what he was talking about so fumbled about for an answer which seemed to satisfy. Methodology? The CEO or salesperson came over and told us what to build. That was our methodology.

Technically there were many highlights (my first exposure to machine virtualisation, switching from desktop Windows to RedHat 9, building a standard SOAP API) and lowlights (rebooting the master database server by mistake when I thought I was logged onto my local machine, building a SOAP API in Perl).

An eCommerce success story

What’s particularly impressive is that, despite the tough climate for tech firms, the company grew and picked up a number of large UK and international retailers as clients. And the company went from strength to strength – just over a year ago, it was picked up by NetSuite for $50m.

Back in 2001, the incumbent eCommerce systems we were replacing were clunky and monolithic. Our solution had its good parts and its not-so good parts but clients loved that we took away the responsibility for managing the platform and left them to run their business. Plus ça change.


Leave a Reply

Your email address will not be published. Required fields are marked *

*
*


Archives