This is the second of a mulitpart part series where we aim to share with you some of the technical aspects of what powers the Managed WordPress Hosting system we developed here at page.ly, how we started, the recent server improvements and a bit on the things to come. [Part 1]
Building a better mousetrap.
Pagely was launched in 2009 after a complete rewrite of the WordPress hosting system prototype we talked about in Part1 of this series. That idea worked, but I think it was ultimately ahead of it’s time and suffered from lack of effective marketing and audience identification.
In late 2009 after many months of re-tooling we went back to the market with an improved managed WordPress hosting solution.
The new system was based on the core logic of the prototype, that being an automated way to deploy WordPress powered websites. But this system had some major improvements which we developed here first, and some of which have since have become the basis for all competitive offerings that have come after.
Pagely 1 introduced:
- Automatic WordPress Core updates
- Automatic WordPress Plugin updates
- Automatic Nightly Backups
- An integrated “Hosting Panel” via a custom developed WordPress plugin that communicates with our core system, wrapping the vital hosting administration tasks like DNS, Email, and Billing management without the bloat of a full Cpanel, or Plesk interface.
- Our one-of-a-kind Whitescreen Eliminator
Initially we emphasized the Choose your Theme aspect and allowed customers to pre-select from a library of chosen WordPress themes. We later downplayed this in Pagely2 as it turned out to be a conversion killer. People would stress over which theme to choose and abandon the cart.
Under the Hood of Pagely 1
Pagely1 was run on the same infrastructure as the prototype we described earlier, a single LAMP box utilzing the Plesk SOAP API. Except we were running PHP 5 by then. Really not that exciting.
Off to the races
Everything worked like a charm, customers were signing up (a modest 100 or so by end of 2009) and people for the most part were ‘getting’ what we were trying to do. Make your WordPress experience better by automating the technical tasks.
The feedback we got was interesting, some people loved it, some people hated it. There are those types that always think “oh I could do X, why would I pay for it” and find no greater pleasure then trolling. Those that got it, got it. We were offering a better WordPress experience via managed automation.
By early 2010 we saw the need to begin scaling as customer count was approaching 500 and our hosting provider at the time was not very helpful. Nothing against them (theplanet) but they were a very hands off provider, basically making sure the server was plugged in and thats about it.
We went in search of a new hosting provider, that would also address our concerns for Security and one that offered more a of ‘managed’ offering that could assist with some of the tuning and setup required.
Thats when we found Firehost.