Sixteen years ago we set out to offer a quality web hosting platform at a reasonable price point to the world at large. With a background in technology, and coming off a string of bad relationships with hosting providers of, shall we say, questionable reliability and service, we knew what we wanted to offer to the world, and we had all the technical aspects nailed down except for one.
We’d need a website. And we’d need a way to keep track of our customers, and those little pesky things like billing cycle dates, resource usage, etc.
We already had a mostly functional platform that we had been using to keep track of our ‘friends and family’ that were already hosting various websites with us. But we knew it’d be lacking many of the features we would now need, so first things first, we took a look around at the world of “ISP / Web Host management software”. We found a couple, but nothing that fit exactly what we wanted. Being technical people, we just decided to carry on with our homegrown platform, warts and all. After all, we could code up anything we decided we needed and add it to the system…. right?
Fast forward a couple years, and we started to run into some issues. Not the least of which was our original platform was written around Microsoft ASP pages, which meant maintaining a Windows/IIS based infrastructure just for our own site, even though we only offered linux based hosting. We had long since fallen in love with PHP as a programming language and diving deep into the old ASP code was becoming more and more of a punishment than anyone desired. And so we found ourselves once again looking at the available off the shelf software packages. And again, we found ourselves wanting something more than the market had to offer.
So in 2007 we launched a new integrated public website and customer management platform written around Drupal, the then king of flexible Content Management Platforms. Tons of custom, self written Drupal module code was pumped out to handle everything from new signups, to billing integration, to auto-provisioning. If it was used in our business, and it had an API (or we could fake one), we integrated it into Drupal.
Over the years since then, we’ve completed 2 major Drupal codebase upgrades, both of which required a massive amount of code-rewrite to keep our existing modules working, while at the same time trying to implement new features. As the amount of custom modules we have under the hood has continued to grow and evolve, each major upgrade has become more time-consuming. In fact, we’d actually started a third rebase of our platform just over a year ago, but it’s never going to ever be completed.
That third, unfinished, and ultimately aborted ‘re-factoring’ to keep up with the latest Drupal core, is what ultimately led us to where we are now, a whole new site, tossing out Drupal and our home-grown Drupal-based management platform in favor of WordPress for content management and an off the shelf hosting management platform to handle the business operations.
The simple fact is, as the industry has continued to evolve and grow, many of the features we originally needed to code ourselves are now pretty standard fare in the world of hosting management platforms. Since both WordPress and our chosen automation platform fully support modules and have a large and vibrant community of people developing modules for them, we can drastically reduce the amount of actual “maintained by us” code under the hood that runs things around here.
Time not spent maintaining those piles of custom code is time we can spend improving our service, implementing new features, and better supporting our clients.
And that’s time much better spent in my mind.