Julian Drake 
Why We Founded a Performance Hosting Company
I kept joking to Matthew Clarkson that we should start a Hosting Company. Then one day we did.
Back in 2004, one of the first things I did after responding to my cousin Harry’s suggestion that I start a digital agency, was to follow his other piece of advice and take out a web hosting re-seller account on a shared server. Within a few years, we were hosting several hundred clients across several servers.
In those early years, in particular, I had many discussions with interested parties about starting a stand-alone hosting company. Each time we would abandon the plans, sensing that hosting would become a commodity business – only profitable on a vast scale.
Big Cloud Commodisation
The emergence of AWS Cloud Servers seemed to further reinforce the view of commoditisation of the industry. I wondered if emerging Big Cloud providers (that also now includes Microsoft Azure, Alibaba Cloud, Google Cloud and IBM Blue Layer) would decimate the Australian hosting industry.
Pelofy
Instead, I decided to focus on developing Software as a Service (SAAS) applications. After a few solo projects that failed to make it past wireframing stage, due to agency commitments, a new opportunity emerged – partnering with Matthew Clarkson. Matt and I had been cycling regulars on the Reverse River Loop. It’s a Brisbane Saturday morning smash-fest that has been going longer than the internet as we know it.
Matt had recently finished up at a tech company and was keen to try new things. So we funneled our cycling passion into our Software as a Service ambitions and decided to build a ride planning app named Pelofy. We were in closed Beta in late 2013 when two things happened. Firstly, Strava.com announced they were adding ride planning to their already impressive cycling performance app. Secondly, the iPhone/Android explosion converged with Facebook groups. Cyclists we rode with were doing a good job of solving ride planning with the Facebook Groups app.
We launched our web app into a competitive space. About 12 months in we noticed something – low engagement. It wasn’t just Pelofy either. Whether it was Strava or Facebook, cyclists were reluctant to commit to rides with their peloton. The right to roll-over and sleep-in may not be constitutionally protected, but it is not something I would recommend any politician who wishes to remain elected tamper with. Without users prepared to commit to turning up, it wasn’t really ride-planning. Besides, our competition were offering event organisation for free and we felt it wasn’t looking like a profitable endeavour. On the upside, we have gained good experience deploying and managing AWS and tuning a mobile-first web-application to be as fast as possible. So we pivoted…
Software as a Service II
So, we began work on a new app – Hilenium. That’s right, Hilenium had a former life. It was to be a workflow app for agencies based on a decade’s experience of running a creative agency and also incorporating lessons we learned from Pelofy. Our focus was on allowing agencies to describe their processes, facilitating the to-and-fro of assets, feedback, revisions and approvals. We used iFactory as the Beta client and it proved its worth, replacing the existing antiquated system I had built over a long weekend years ago.
Two years into development, and with no paying customers, we needed a break. I urgently had to find a new home for iFactory as the warehouse we were located in was being redeveloped. Several months of renovations of the new building lay ahead. Matt took a contract with a social media influencer startup. As per usual with construction projects, they drag on. After moving in, we were busy for a month getting parts of the building completed.
We Were Slow
In the doldrums between completing the new office and restarting on the Hilenium App, several things caught my attention. Firstly, an experience with a client who was a major retailer. One of our server providers had a major outage taking our client’s website intermittently offline for several days. This client had been complaining of poor site load speed earlier in the year but it seemed to improve after several months. We had only been monitoring for uptime and had shrugged off the speed issues as erroneous. This major outage forced me to review the logs. I noticed that months earlier the site had gone from a typical 1500ms monitoring response time up to 6000-8000ms for weeks at a time. The client had been right and we had done nothing! I felt this reflected badly on our service.
A few months went by and I had started monitoring not just uptime, but also response times. I noticed response times started getting slower on another server, this time with a different vendor. After reviewing the data I logged a ticket with the server provider. Their response was “it was a website configuration issue”. Furthermore, they believed they had comprehensive metrics to prove it. I went through their metrics and rectified every issue. I waited several days to collect new response data, as the monitoring system checks every minute. The website speed did improve but it was still much slower than the servers historical data, so I re-submitted the ticket. After further discussions, the server provider realised they had a performance issue and resolved it.
Fast Again
As a result of this process, the website was faster than ever. A web developer had helped a web host improve their server speed and a web host had helped a web developer improve their site speed. I had a moment of illumination: Was there a business model in improving and monitoring websites, helping both web developer and web host keep sites fast? Would people pay for yet another service provider in their lives?
Over the next few months, I took some time to see if I could make all our highest traffic sites faster. We managed to transform clunky Drupal, Magento, Joomla and WordPress installations into snappy, blazingly fast marketing tools. We were happy with ourselves, until a few days later when one of the websites regressed back to slow. Clients make sites slow too. They log in to the Content Management System and disable speed-related features often accidentally. Sometimes they need to do this to see website changes they have made. The problem is, they forget to turn the speed back on. It dawned on me to keep a website fast you needed access to both website and web server. The only way to guarantee this access was to be the web host. Keeping websites fast had to be part of a web hosting solution.
Hilenium II
On my next catch-up with Matt to discuss the future of the Hilenium workflow app, I raised this hosting idea. We also reflected on research Matt had recently provided me on the revenue reality of the vast majority of SAAS apps: Few customers, small revenue and most were losing money. It is a popular meme that most software developers are building ‘Abandon-ware’. A few days later, I stumbled on a YouTube documentary where a VC spoke about the existence of over a million start-ups in the EU alone. We reasoned that globally there must be over a hundred thousand productivity SAAS apps.
The Hilenium workflow app had given us great experience using a full suite of AWS tools, including EC2, RDS, S3, CloudFront and Elastic Beanstalk. We also became well -versed in speed optimisation, continuous integration, API testing, automated end-to-end testing, application monitoring, client support and communication systems. As a result of this, we had been provisioning AWS for our agency clients.
So we took a leap into the known. Solving a known problem with known technology. Hilenium Hosting was born. It would be a new type of hosting company. We would utilise third-party servers known to us. Website optimisation solutions are known to us. Performance monitoring tools are known to us. We would not build websites or cloud servers, we would just make them faster. If they stopped being fast we would tell our clients and offer to help. We would work with web developers to help them keep their clients fast. We would use our monitoring and benchmarks to help server providers identify and resolve issues. Hilenium would have a razor-sharp focus. Performance Web Hosting that’s Fast & Found.
Matt has also written on this topic from his perspective in Why We Are Different To Traditional Hosts.