Subscription Analytics: Build Versus Buy

Everything you need to consider before you’re ready to make the Build vs Buy decision for your subscription analytics platform.

At ChartMogul, we are lucky to talk to many companies in the SaaS space and see the spectrum of challenges each faces at each phase of their growth.

Depending on where these companies find themselves along that spectrum, we can find ourselves in conversations with teams that are comparing our Subscription Data Platform against a tool they are planning to build internally.

Naturally, we want to get as many customers for ChartMogul as possible but are also very aware that for some teams, only an in-house tool can provide the level of insight they need.

Our experience has helped us develop a good understanding of what characteristics make a team a good fit for build vs buy.

In this post, we want to share some of that knowledge in order to help companies that are trying to decide whether they should build or buy their subscription analytics software.

Further reading

Some additional interesting takes on the “build vs. buy” conundrum:

• Build versus buy. by Will Larson
• SaaS billing build vs. buy by Shar Darafsheh

Both Build and Buy involve tradeoffs

Many teams choose to “buy” because they want to start using their data to their advantage as quickly as possible. Similarly, quite a few teams choose to “build” their solution in-house because they believe their use case is so unique that nothing in the market comes close to fulfilling their requirements.

No matter which approach you choose to go with at the end, it is important to understand you will always gain and lose something (speed vs. customization, etc.)

To make that decision for your company, it’s not enough just to be aware of the advantages and challenges of each approach. You also have to develop a high level of understanding of both the business and technical requirements you have to fulfill to decide which approach would work best for your company.

• What does a solution need to do, and how will it be managed and iterated on over time? 
• Who are the user groups that will interact with the solution, and how will they use that solution? 
• If your CFO needs to use the solution to build EOM and EOQ investor reports, they will need the solution to be reliable and consistent.

Let’s compare the two approaches and see how they stack against each other.

Building your own analytics tool

Building from scratch may appear to be a good option because it allows you to create a tool that is the perfect fit for your specific business model.

However, you also need to consider that it is improbable that you will get the resources to build this vision of the perfect tool. One of the reasons is that investing in something that is not part of your core differentiator is probably not a great use of your resources in the first place.

Especially in the beginning — you’re much more likely to start with something that looks a lot like a proof of concept than the complete platform you envisioned during the planning stage.

Here are some of the other pros and cons building subscription analytics internally comes with:

Positives:

• Complete control over how metrics are calculated;
• Fits your use case 100%, you can create any charts/features you want;
• You can integrate with any of the other tools you’re using.

Negatives:

• There are significant costs associated with setting up your infrastructure and developing the software you will need;
• Building the initial proof-of-concept version is relatively easy, but generating proper charts, maintaining them, and making sure they are accurate gets increasingly complex and challenging;
• Any additional functionalities and integrations need to be built on a custom basis by your team.

Over time, the volume and complexity of the data your solution needs to account for compounds and your business and technical requirements change. So when planning for your solution, you need to anticipate that you may change billing systems later on and to be prepared to build support for that if and when the time comes.

Now, let’s look at what this looks like when you decide to buy a pre-made subscription analytics product.

Buying a third-party analytics product

Two distinct motives usually drive teams that choose to buy an analytics platform.

The apparent reason is, of course, to save time, money, and engineering resources.

The equally-important-yet-less-prominent motivation is that an external vendor — especially in the case where they are developing analytics for a specific niche — also brings deep domain knowledge about the area you’re interested in.

So, whether it’s revenue, marketing, or product analytics, companies like Mixpanel, Heap, and others spend a lot of time thinking about the underlying discipline. I know we do.

Besides, buying from an external vendor means you are (almost) guaranteed that the company will continue to develop the tool, so you’re using something that is always following the latest trends in the industry.

Just as with building, buying an analytics platform requires a set of tradeoffs.

Positives:

• You can get started right away with minimal time investment, and your engineers can focus on your core product.
• Metrics calculations are based on deep domain knowledge, and they are thoroughly vetted and trusted by leadership teams and investors the world over;
• Most integrations are built by the vendor and work out of the box;
• The product is improved continuously by a dedicated development team focused on implementing the latest thinking and trends in the field.

Negatives:

• The vendor might be unwilling to consider and customize the product for your specific use case if it doesn’t apply to a larger share of customers;
• Most tools focus on a specific niche/type of analytics, so you can’t perform every kind of analysis in one place;
• Sometimes, you will still need to dedicate some developer resources (for example, when trying to import data that lives in a legacy system).

Now that you have a good understanding of the tradeoffs each approach involves, you should also consider the resources building internally would require.

What does it take (and how much does it cost) to build your own analytics?

If you’re thinking about building a subscription analytics capability internally, it’s important to consider the requirements and costs of such a project.

First, in terms of technology, you will need to provide solutions for the following three layers:

• Data warehouse: As the name implies, this is where you will store all your data. Essentially, this is a database optimized for the types of analytics queries you will be performing. Typical examples of this include Amazon Redshift, Snowflake, and Google BigQuery.
• Extract, transform, load (ETL): This piece of your setup will be responsible for extracting your data from your primary database, transforming it into a pre-defined format, and loading it into your data warehouse, so it can be used to perform analyses. Examples of this layer include Fivetran and Stitch.
  ○ Even if you are only going to analyze data stored in SaaS/cloud services, you will still need to write (and run) your own scripts to extract, transform, and load the required data into your data warehouse.
• Business intelligence/Data visualization: The final piece is the solution you’ll use to perform queries and display the data you get from them. Typical tools in this category include Looker, Tableau, Power BI, Google Data Studio.

In terms of costs, it can be challenging to estimate the exact amount to build internally. Many of these tools cater to larger organizations and, as a result, don’t have public pricing available.

Based on some of the information we’ve been able to unearth, building a best-in-class solution can easily require northward of $100,000 per year (excluding headcount costs!) to build and operate:

Data warehouse: Pricing depends on a range of factors such as the number of nodes and cluster sizes you will require, but our estimates suggest that using Redshift/Snowflake would start at between $5,000-8,000/year;

ETL: Adding FiveTran would add around $20,000 to the bill;

Data visualization: Looker is the priciest piece, with some reports putting it at over $50,000.

Of course, you will also have to consider a full-time data engineer’s salary that you will need to build the solution in the beginning and a data scientist that will be the primary person who will be using it. The average salary for both those is over $100,000 per year, according to Glassdoor.

As you can see, the costs to build a “best in class” solution can quickly escalate into six figures, so it is essential to keep that in mind when choosing which approach to take.

Some teams choose to build using cheaper and/or open-source products, but that introduces a whole different set of challenges and usually, it ends up requiring even more data engineering effort, which makes the end result just as expensive.

With that, we do not want to imply that you should also choose to “buy” over “build”. In fact, we believe there are circumstances in which either can be the better option.

How to choose between Build vs Buy

We believe that your decision to build your own solution or buy from a third-party vendor should be driven by what end goals you want to achieve.

Suppose you’re looking to implement analytics and start using the insight from them in well-defined areas such as marketing, product, or revenue. In that case, it makes sense to buy from a vendor who already has built a dedicated product based on the expertise they have in the field.

However, suppose you are more interested in exploratory data analysis, precisely in cases where you can combine different types of data (e.g., specific types of in-product usage and revenue/subscription movements). In that case, it makes sense to invest in building your own stack and hiring a (team of) data scientist(s) to run this for you.

We also increasingly see a trend of what we call Reverse ETL. Companies with a high level of maturity in their data operations connect their data warehouses to tools like ChartMogul to take advantage of pre-built integrations, metric computations, and other features. This preserves their control over data and gives them the ability to do any type of consolidation and analysis on their end.

Some ChartMogul customers also use our Metrics API to pull their metrics and present them in their preferred reporting solution/stack.

Pick a side, make a move

No matter which route you choose to go, we believe making a move is inherently better compared to pondering the decision too long.

A lot is at stake when it comes to your data and how you use it. There’s a lot in it that can help you understand the potential of your business and grow it sustainably.

If you’re currently facing some of these issues and would like to get a second opinion from an expert (it will be only slightly biased, we promise), our team can help you define your business and technical requirements and avoid any serious pitfalls.