Normally, posts to our blog are about news. New features, changes or something else timely and topical. But today I wanted to post something personal and heartfelt - a message of thanks, a reflection on how far we've come together, and a glance at where we're going together too.
Three months ago, as many of our users had signed off for the year to enjoy a bit of a break over the holidays, I was putting in place some ambitious plans for the first three months of 2014. There were so many changes, so many challenges, that I knew it wouldn't be completely smooth sailing. Now, as we close in on the end of this tumultuous period, I wanted to give you a bit of a peek behind the curtain and share a very big thankyou with you all.
Since we launched Accelo in November of 2011 we've been working furiously to iron out the kinks and improve the product for our thousands of users. Some of those bugs and kinks have been relatively easy, but others have been really all-encompassing and hard.
Probably the hardest ones to upgrade and improve also happened to be one of the most important - the Projects Product. Projects are how most of our clients make most of their revenue, so upgrading this big and complex product and making it both more powerful and easier to use at the same time was a daunting challenge to say the least.
As some of our users will know, not everything went smoothly. Some of the hiccups included:
However, a lot of impressive things went very smoothly indeed, including:
These improvements to the projects product would not have been possible without the feedback, suggestions and patience of you, our users. We're exceptionally thankful for you helping us make the new projects product the success it has become, and for working with us to continue improving it going forward.
Our big Feb project fit squarely into the "under the hood" category - we moved all of our infrastructure from an array of bare-metal physical servers and moved to the cloud proper with Amazon Web Services.
Previously, Accelo was running on a sort of "private cloud"; we leased servers from a top-tier hosting company (now owned by IBM) and ran our system hosts as virtual machines (KVMs via qemu for those interested in the geeky stuff). We'd implemented this setup in consultation with a company we had engaged before we launched to ensure we had a setup which was as secure, scalable and optimized as possible without needing to spend tens of thousands of dollars a month up front.
Unfortunately, we chose poorly.
While at the time we were making these decisions cloud offerings from Amazon and others were not well suited to enterprise and custom security requirements, the rate of innovation meant that the concerns we faced and changes we'd need to make to go with someone like Amazon were quickly being eliminated.
At the same time, the incredible shortcomings of the old fashioned way of doing things - renting (or worse buying) servers, buying bandwidth, managing patches and doing all this with outsourced vendors who were expensive and opaque was horrible.
Over the last 3+ years our team suffered hundreds of hours of frustration and wasted time waiting for third parties to do even the simplest of things - thankfully for our clients, only a very small number of these occasions had direct effects on uptime, but the ones our clients didn't see still tied up our best people and stopped them from delivering product improvements as quickly as they might have otherwise.
Our primary service vendor would justify their opacity and inability to give us direct control because the work they were doing needed constant documentation and change management, which our involvement would break. When you're trying to manage a complex network of servers and you want to be able to scale them, having things clearly documented and build processes automated is key. While frustrated at being kept at arms length, I reluctantly accepted this advice, until in the middle of last year when after a series of outages it became increasingly clear that the promises of careful change management were hollow at best.
We suffered two multi-hour downtime periods, both of which occurring because changes made over 6 months prior hadn't been committed to permanent configs, much less documentation. Fool me once, shame on you, fool me twice... but by the time we'd been let down for a 4th time for the same problem, it had gotten well beyond a joke.
At this point I resolved to take direct control back of our destiny no matter what, and hired our first full time internal sysadmin in October. We spent three months going through an exhaustive research and testing process to make sure we chose the right cloud provider (and understood what would need to change in our product and code as a result) - in the end, we selected Amazon Web Services, who it is estimated has 5x the capacity of the next 14 cloud providers combined.
A further complexity we faced in this upgrade is that we decided to upgrade the version of the underlying code and libraries we used, uncoupling them from the operating system's (very conservative) settings and dependencies, and upgrading them to be much faster and more modern. In effect, in one fell swoop we implemented more than a decade of changes and fixes to underlying libraries, and any one of the hundreds of thousands of changes applied could have hurt us and caused problems.
Over the holidays and into January we ran parallel environments, undertaking extensive benchmarks and tests to ensure we'd have as few surprises as possible. Of course, the variety in real-world client setups (from how they route emails to Accelo to integration with platforms like Xero) meant that we did see some surprises and headaches during the cut-over. While they were mostly small and addressed within a day or two of the upgrade, we're still sorry for any inconvenience experienced.
There's a lot of things that go into how fast a web application loads, and many of them (like the public internet, speed of a client's web browser and computer, etc) are out of our hands, the one thing that is in our control is the speed of our environment. Our benchmarks suggested that pages were loading 40% faster in Amazon's cloud than our previous private cloud setup - but it wasn't until we were loaded up in production that we were able to see the results for sure. Amazingly, they held up; one of our users in Denmark sent this email in the day we went live:
"Hi Geoff - super speed improvement on the new setup".
- Kasper from Prentow
Once again, we couldn't have done this without the support and patience of our users. Changing infrastructure providers is like having to move an entire village while everyone is asleep and hoping they don't notice. The patience of our users during the rough periods of 2013 that made this essential, and the support and understanding during the cut-over have been incredible, and all of us at Accelo really appreciate it.
As if we hadn't already taken on enough challenges already so soon in the year, March has been a month of massive behind the scenes work as we made the biggest changes we've made to the business since our launch in November of 2011.
While much of the Accelo team were enjoying a well-deserved break over the Christmas and New Year period three months ago, I was deep into planning mode. In the previous two years we'd grown strongly, but I realized for us to really make a meaningful impact in the world we'd need to get a lot larger.
The challenge: what do we have to do to be 4x larger at the end of 2014 than we were at the start?
While the math is easy - 14% compound monthly growth - I knew making it happen would require more than just doing the same as we'd been doing previously.
After a lot of research and reviewing of data, we realized that we needed to make Accelo available in bite-sized chunks to make it easier for new users to adopt, we needed to make the pieces of the product fit what our target market wants (which may be different to what they need, at least in the long term), and we needed to be focused on the professional services sector.
We then needed to work super hard to drive awareness through thought leadership, marketing, events and driving word of mouth - all of which would be helped by aggressive pricing and clear communications.
Making this a reality is of course easier said than done, but over the last couple of weeks we've:
For most of our users, these changes weren't noticed at all; we did have a few hiccups with some users who were on special one-off plans for one reason or another which didn't port as smoothly as they should have into the new platform.
For those who experienced any inconvenience, I'm really sorry.
There's still a lot of exciting product development work going on day by day, and we're looking forward to bringing you an update post in a week or at the end of the quarter to share updates on progress and priorities in Q2.
Beyond the specific product features and the quarter-by-quarter roadmap deliverables, the one thing I did want to say is that we're focusing 100% on being the best way to manage a professional service business in the cloud.
When it comes to knowing the health of your business - how profitable it is, how productive your team is being, which clients are the most lucrative (and what you're really spending to support them) and many more things - we want to be your business bible. Combining these insights with the business processes we're known for, the notifications and reminders we've got coming around the corner and new interfaces to make it easier than ever for your team to do their work is what we're all about - and we can't make this vision a reality without your help and support.
Thanks for joining us on this journey - we're thrilled to have you along and can't wait to make tomorrow better than yesterday, together.