When we launched our free plan recently, we weren’t sure whether customers would routinely want to upgrade from the free offering to a paid subscription. Of course, we hoped that would be the case but, in the absence of concrete data, we always try to keep new functionality as simple as possible. Our MVP was a plain signup form to create the account and page with a message asking customers to delete their account and sign up again for a paid plan if they took an action that initiated an upgrade.
We knew going in that this would not be an ideal experience for customers that wanted to upgrade and over the course of a few weeks, we heard from a handful exactly how dissatisfied they were with the process. With a few strong data points, we were able to make the decision to prioritize this work and deliver a new, easy upgrade process for those customers that want to benefit from our paid features. The entire process has just three steps.
1. Create a CodeGuard account with the free offering.
2. Select the upgrade option from the dashboard to see the available plans (image below intentionally large).
3. Pick the plan that best suits your needs.
4. Enter billing information to initiate the new subscription.
This process of releasing and testing a small feature with “obvious” follow-on work, rather than doing all of the work up-front may seem counterintuitive to some. However, we have learned that our assumptions about how a new product or feature will be used do not always perfectly match what our customers need. So, rather than building something that we think is ideal, we release the smallest possible feature, make incremental changes, listen to or observe customers and iterate to build something that customers actually value.
In one of our recent blog posts, we talked about the improvements we have made to integrate our WordPress plugin with our main CodeGuard dashboard. One of the issues we faced when working on this integration was making sure WordPress plugin data are synced with the dashboard quickly so users see changes in close to real time.
We’ve talked about how the CodeGuard WordPress plugin works in the past, but just to give you a short refresher: The plugin first scans the WordPress root directory for files. It splits this content between several small zip files that are then transmitted and safely stored in an Amazon S3 storage account managed by CodeGuard. Combined, these zip files make up a single backup. We also upload log files that can be used to determine which steps in the backup succeeded and which steps failed, as well as an integrity check that we use to verify all of the zip files are present in S3. In order to make details about the backup accessible in our main CodeGuard dashboard, we needed a way to analyze the information stored in S3 and record statistics in our Rails app database that we could then display to users.
Read More “Realtime Syncing with AWS Lambda”
We’ve talked before about some of the architecture we use to back up hundreds of thousands of websites and databases using FTP, SFTP, SSH and MySQL, but many of our customers have opted for the simplicity of our new WordPress plugin. In keeping with our other behind the scenes posts, we wanted to share a bit more about the technical aspects of the solution for those that are curious.
Read More “Behind The Scenes: CodeGuard WordPress Plugin Architecture”
Successful web applications, like the businesses they embody, require care and feeding. We all have visited, at some time or another, a mom-and-pop business where the owners are friendly but the floors squeak and some of the back corner items require a little dusting before purchase. Such places can be quite charming in their way, but clearly they stay alive because of a lack of competition and the simple expectations of their owners.
Read More “Diligent Care and Feeding Grows Our Web Services”
2016 has so far been a very dynamic and exciting year for CodeGuard. On the product side, we released a brand new WordPress plugin that fully integrates into our existing dashboard and began development on multiple features for our existing customers. In the community we’ve been building new relationships by attending conferences and sponsoring local ones. We’ve even added a few new members to our growing team! Needless to say, life at CodeGuard has been quite busy. While it’s true that we’ve been focusing on many things at once, there is still one part of CodeGuard I felt could use a little more attention. That is why at the beginning of this month I decided to redesign the CodeGuard blog. I had a lot of fun with this project, and would like to share some of the lessons I learned along the way!
Read More “Redesigning the CodeGuard Blog”
As you may have read in our previous blog post on using Go, we at CodeGuard use the new programming language, primarily developed by Google, to optimize the speed of our services. Sometimes we notice that one specific part of our system is getting heavy use and potentially slowing down the rest of the experience for our users. Imagine a road that engineers notice is often congested. They may choose to add more lanes to the road, to improve traffic signal timing, or to speed up alternate routes. As a part of our work here, we revise the parts of the system that our users traverse the most in order to improve our customer experience, and at the same time to lower our costs. This is a win-win result all around. However, there are other ways that we have leveraged this new programming language in the CodeGuard system to deliver features more quickly. This is one such story.
Read More “Thin Wrappers – Delivering Services Quickly with Go”