Pricing Teardown: Code Climate

Friday, January 16, 2015

Disclaimer

This article is part of a series of pricing teardowns for companies and their products. I have no private information about their profitability, no knowledge of their business goals and (possibly) no particular background in their industries. I intentionally avoid performing research on what others have said as well as writing in the companies' blog posts and twitter feeds. I do this so as to ensure that my evaluation is based entirely upon their websites. As such, this analysis may contain invalid assumptions and plenty of guesswork. Fortunately, this makes the resulting analysis much more fun.

Introduction

Today is an exciting day! Why? Because it's time for another pricing teardown. Today we'll be looking at Code Climate, a tool for software engineers. A developer I know mentioned it in passing, and I just had to take a look.

What Are they Selling?

The first question I ask when I go to a company's website is "What are they selling?" Some firms present their value proposition fairly well, while others dance around this important matter. The website's tagline is "Merge with Confidence. Automated code review for Ruby, JS, and PHP." While this will likely leave many businessmen confused, many software engineers will instantly see the word "merge" and know that the product has something to do with source control. The "automated code review" leaves a bit of wiggle room. The firm has not yet established what it reviews the code for, but at least we know that the product is an automated tool. The list of supported languages at the end allows potential customers to instantly decide whether or not this product is compatible with their software systems.

Having read a mere eleven words, I already know that the product is something that inspects code as it is submitted to a versioning system. Further research stronger implies that git is the only support versioning system, but given the use of other source control products by legacy systems, it would be a good idea to point out this limitation explicitly.

As I scrolled down the front page, I noted that the firm had highlighted four broad categories of benefits for its users:

• Quality
• Security
• Style
• Test Coverage

There are many software developers who place a great importance on each of the above areas. That being said I do wonder if it was a good idea to include the "security" section. Although the product is touted as one that works with three languages, it appears as though the tool can only scan ruby projects built with the rails framework. If scans related to the security of JavaScript, PHP and vanilla Ruby are being developed, this would have been a great place to mention it. Otherwise, the firm is highlighting an important gap in functionality for many developers.

Similarly, the style section speaks to the fact that the functionality is "coming soon" to Ruby and PHP. It is unclear whether or not style checking has been implemented for JavaScript at all. I again question the wisdom of using prime real estate to emphasize functionality that is not yet available to many of the firm's potential users.

Who Is the Customer?

It's unclear if the site is focused on selling to developers or to businessmen. If it is directed to developers, the product description should have substantially more detail. For instance, what are the 20 different types of common rails app vulnerabilities that the site mentions on its front page?

If the intent was to speak to managers, I would have expected statements regarding the expected ROI (return on investment). How much more expensive is software to write when developers don't use tools like this one? There's a fantastic quote on the pricing page from a user testifying that he "signed up yesterday and got [his] money's worth today." The firm should waste no time in writing about his experiences.

Walking the line between two options (in this case, appealing to both businessmen and engineers) can be difficult. Choosing a side will allow the firm to select the appropriate vocabulary and concepts. While a good software engineer will instantly see the value of a tool that analyzes cyclomatic complexity, the average manager would rather hear something like "reduces development costs by minimizing required maintenance expenses." The average manager might not understand why maintenance expenses go down because of that, but he will generally know that expenses are bad, and avoiding them is good.

Let's Take a Product Tour

I decided to take a look at Code Climate's tour page.

The page contained links to a ten-part tour. I didn't see any obvious method to the ordering of the pages. The firm should have considered breaking the ten items into the four broad categories laid out on the main page (quality, security, style and test coverage). Had the developers of the site chosen to do so, they might have discovered that there is no obvious display of how the tool indicates the quality of code "style" (as far as I can tell). If style is an important measurement (it represents a full third of the areas of functionality described on the front page for non-rails projects), it should be highlighted in the tour.

Without a stop on the tour to highlight how style evaluation works, it will be unnecessarily difficult to defend the purchase of this product for those concerned with code style. Yes, potential buyers could perform additional research on their own, but why force potential customers to perform research on sites that is not under the control of the firm? They might become enamored with another vendor's product while conducting this research.

Finally! The Pricing Page

With an understanding of their offering, I then turned to the company's pricing page.

Those who have read my book on software pricing know that I questioned Microsoft's decision to release an astounding six different versions of Microsoft Vista in the American market (11 if you include the 64 bit versions). I'm similarly astonished by the eight pricing tiers of Code Climate. That being said, the company was able to reduce the confusion experienced by Microsoft's customers by hiding many of them behind text links. Doing so reduced confusion and limited distortion to the price anchoring that had been employed for the three primary plans.

The pricing page lists the three main pricing tiers in big print. Below it is a smaller advertisement for a tier designed for open source developers. This tier made a great deal of sense as it will allow software engineers to learn about the product and hopefully provide the knowledge necessary for them to evangelize the product at their places of work.

Below the free plan (in tiny print) were links to learn more about the four additional tiers:

• solo developer
• bootstrapped startup
• student
• non-profit

I understand what they're trying to do here, but it should be simplified quite a bit. For instance, the solo plan could probably be combined with the student one. For the sake of simplicity, I'll just examine the main plans ("team," "company" and "enterprise").

Much of the screen real estate used to describe the three plans is not only redundant, but also harmful to the company's messaging. Each plan has three green check marks for the three items that are included in every plan: "email alerts," "security monitor" and "branch comparison." There are no check marks anywhere that correspond to a feature not found in any other plan, so the average customer might be lulled into the belief that all three plans are largely similar.

It's unclear why a user might want "email alerts" or what they are used for, and it's very misleading to specify that all plans include the security monitor when (at time of writing) the security monitor is only available for ruby on rails projects. Not only that, but the branch comparison functionality seems an odd choice to highlight, given that its corresponding screenshots were buried in the middle of the product tour page.

Pages that display pricing tiers should highlight the differences between the tiers (if not to upsell customers, then to ensure that customers can easily select the most appropriate plan). By blurring the differences between the plans, this presentation risks "downselling" potential customers.

The descriptions of each plan (printed atop the orange backgrounds) are similarly putting the company at risk of losing out on potential profit.

• The "team" package may be the most popular (as stated), but there is absolutely no reason to highlight that fact. Many products emphasize the popularity of the mid-tier option in order to convince customers to upgrade from the bottom-tier offering. The language here could cause people who are thinking about purchasing the higher-tier plans to downgrade to the team package because it is seen as a safe choice. If so many other people are choosing it, perhaps they should choose it too!
• The "company" package could use some labeling improvement as well. It's great that the firm highlights that it comes with support "for multiple projects," but unless I misunderstand the nature of git, the less expensive "team" package supports multiple git repositories too.
• The "enterprise" package labeling states that it is designed "for large organizations," but 32 users really doesn't seem like that many people to me. Perhaps it's because I cut my teeth at a company with nearly 100,000 employees. Certainly there are many organizations with the need for larger numbers of users. Granted, there is a tiny note at the bottom of the page that allows customers to request more "repos" or users, but I think that the enterprise package should really be geared to enterprise customers. Removing the price and exact offerings from the enterprise tier would allow very large company to consider this product and allow Code Climate far greater flexibility in creating custom pricing for reasons I detailed in my pricing teardown of SketchDeck.

There's one additional point that I'd like to highlight. As I describe in my book on software pricing, I strongly dislike the common strategy of reducing per-seat pricing at higher-priced tiers. Larger companies are often the exact types of customers with the ability to pay larger per-seat prices. A much better idea is to charge more per user and then offset this per-seat increase with features that cost relatively little to add and support.

Summary

I've heard great things about Code Climate's product, but a great product is rarely enough to ensure a future of strong profits. The firm should focus some additional attention on its marketing strategy.

• The company should figure out to whom they are selling (technical staff or businessmen) and then tailor its messaging accordingly. In either case, the firm should focus on outcomes (like cost & time savings) rather than functionality (test coverage & style).
• Another look at their tiering strategy would potentially allow them to simplify their pricing strategy and target different types of customers more effectively.

Blatant Commercial Pitch

Do you need help with your pricing strategy? Want to make sure that you're not leaving large sums of money on the proverbial table? Then you'll certainly want to contact me for a consult!