KCover image by Andrik Langfield on Unsplash
Purchasing new enterprise analytics solution can be a great experience if you've never purchased software before, yet can be a daunting task. There can be a variety of analytics vendors with overlapping features for a use case yet each has their strengths and weaknesses. As an alternative to purchasing ready-made SaaS, you can also build your own in-house API analytics infrastructure on top of open-source software like Spark, Druid, and Elasticsearch. This article digs into when it makes sense to build vs buy ready-made analytics solution and provide a point based framework for evaluating API analytics solutions and perform the proper diligence.
The first decision a company should make is whether they want to build the infrastructure or purchase a ready-made solution. There are benefits and risks to both. In general, purchasing shortens the delivery of a well-polished analytics solution with lower cost in time and money compared to homegrown, but a homegrown gives you greater control over what is tracked and presented.
Answer the following questions starting with a point scale of 0.
When to buy?
Add 1 point if you answer yes to any of the following:
Are you resource constrained?
Buying a ready-made analytics solution is almost always cheaper than building and maintaining a homegrown solution yourself. Vendors can amortize the R&D cost to build high performance infrastructure that's scales to billions of API calls across many customers. In addition, ready-made SaaS solutions have almost zero maintenance overhead whereas homegrown solutions accrue technical debt over time due to engineer turn-over, product neglect, and evolving business demands.
According to SAP, 78% of homegrown enterprise apps are abandoned after first use. Feature and bug fixes (even critical security fixes) remain unresolved after the initial delivery due to engineering resource reallocation. If you don't have a data infrastructure team dedicated to maintaining your homegrown solution,
it almost always makes sense to purchase.
Are you time constrained?
Due to feature creep and unexpected onion peeling, building a usable analytics solution can drag on for months or years even for the fast moving teams.
Fully-managed SaaS solutions take less than a day to get up and running. Every day your team is building analytics infrastructure is time not spent on building customer requested features that drive your bottom line growth. Buying allows you to invest your efforts into your core competencies rather than reporting infrastructure. If it takes six months to deliver your first iteration of your
analytics solution, then that's a six month delay in data collection and having access to proper data causing suboptimal planning and execution.
Is real-time performance important?
Do you care if new data shows up the next day or are you looking for real-time monitoring and anomaly detection capabilities? Vendors can invest larges amounts of resources to make their solution high performance and real-time which are necessary if you want real-time alerts on API and account level health. To shorten schedule, homegrown systems are usually built on existing technologies like SQL and Hadoop, where as a vendor can invest much more resources into custom-built data stores and infrastructure.
Do many teams need to access the data?
Company-wide tools require strong access controls, audit logs, data management, along with a easy to use interface to make data accessible by non-technical users
that a ready-made solution already has built in. A homegrown API analytics solution is usually designed by engineers for engineers, forcing non technical users to rely on making requests to an already overloaded data team. This slows down time-to-insight drastically.
In addition homegrown solutions usually don't have any security features in place due to aggressive schedules to build quickly. Majority of security incidents are due to insiders rather than third parties, sometimes inadvertently due to employees sharing passwords, employees unaware of proper IT-security policies, and no automatic threat detection of homegrown systems. Just because it's behind the corporate firewall doesn't mean it's immune.
Is your team unfamiliar with privacy and compliance laws?
With regulation like GDPR, CCPA, and the upcoming ePrivacy Regulation being introduced, enterprises are now having to navigate more regulation than ever.
Homegrown analytics systems rarely have frameworks and features in place to deal with things like GDPR's right to erasure and methods to stop collection of a specific user or company. Ready-made API analytics solutions from a third party vendor usually have additional features and frameworks already in place to make this much easier for their customers. After all, their main business is selling compliant API analytics software.
Do you require specific integrations?
Will your API analytics solution be used by engineering only, or do you expect other teams like product, marketing, and customer success to also leverage your organization's API data? If so, each team may have their own workflows and tools of choice. For example, engineering might be using PagerDuty and Jira, product using Amplitude and Segment,customer success using Zendesk and Salesforce, and finally finance using Tableau and Slack bots. Will you be building integrations with each of these products? Otherwise you may have data silos which decreases the usefulness of API analytics and slows down your organization's productivity. A ready-made solution usually has an ecosystem of plugins and integrations.
Do need expertise in data science and creating the right API metrics?
Because of their experience helping many companies leverage API analytics, vendors usually have deep expertise that they can share with their customers on best practices and ways to leverage API analytics at your organization. They're able to provide a framework to build a better platform and can point you to tutorials and other know how that can assist your organization.
Homegrown systems are usually built without any input from experts in growing API platforms and what to measure. A partner with deep expertise in API analytics can help you get started tracking core metrics like TTFHW (Time to First Hello World) and walk you through best practices for API cohort retention analysis while understand what custom metrics are important for your business.
When to build?
Subtract 1 point if you answer yes to any of the following:
Are you in a highly-regulated industry?
Certain highly-regulated industries like healthcare and banking have very specific requirements on where data is held and the type of data that can be collected such as with HIPAA compliance. In these cases, it makes sense to build your own system to have complete control over data and not rely on a third party vendor. While most third party vendors already follow general best practices
for SOC 2 and ISO compliance and have hardened infrastructure, but may not have industry-specific compliance like HIPAA. If they do, it may require a special plan.
Regardless, it's imperative that you're homegrown system is also compliant. Don't fall into the trap of assuming internal systems are immune to compliance.
Do you want complete control over the look and feel of information?
Building an analytics solution gives you complete control over how information is presented to end-users.
While many ready-made solutions do provide ways to customize dashboards and white-label for customer facing portals, if you have very specific requirements,
you will need to build that in house.
Do yo have a specific road map of analytics features and metrics to track?
Does your organization have a well defined road map of what analytics features are important now and in the future.
Do you believe the vendor cannot keep up adding more advanced features? Does your team have certain trade secret metrics that no other company is tracking?
If you're unsure what's the best way to measure, a read-made solution will come with a well defined framework so you don't have to think about which analytics features are important, but this can limit you in measuring very specific things.
Do you have dedicated data engineering resources?
Do you have a dedicated data engineering teams and data science teams to build and maintain this? Have they already built and supported analytics infrastructure before at your organization?
A dedicated team is not constantly context switching between feature development and building analytics infrastructure. This gives them more time to spend on maintenance and improvements.
Does having analytics in-house give you a competitive advantage?
If you're building and selling a payments API and your main competitive advantage is that payments can be made in every global currency and can occur even offline without internet service, it would make sense to build your payments infrastructure in-house. On the other hand, unless you're in the business of selling analytics solutions, it makes sense to partner with a vendor that already has deep expertise in analytics that can supplement your own engineering expertise rather than reinvent the wheel. The vendor can bring not only their infrastructure, but also know how on what are the best metrics to be tracking and how to track them better.
Do you want to open-source your analytics infrastructure?
An overlooked benefit of building your own analytics infrastructure is you can also open-source it. If your company has a friendly policy for open sourcing internal tools, it can be a great way to boost recruiting efforts especially if you're trying to recruit more data engineers. Since you have full control over the analytics platform, you can do as you please. If you do plan on open-sourcing, make sure you make that decision early. Open source projects have a higher bar to code cleanliness and also need to be able to run as a single container without require many dependent services to be stood up. If your analytics infrastructure depends on many components like a SQL database, Hadoop, Spark, and Kafka, it may be harder to open-source.
Do you have a very narrow use case?
If you have very specific use case and don't intend to grow from there, building sometimes makes sense because you can over optimize on compute and disc space.
This is one of the hardest ones to decide on since it's hard to plan for unknowns. If you want to track one single metric, and know that's all you need, then buying a solution may not make sense. However, be careful of the fallacy that today's use case seems specific, since as more teams start using your homegrown solution you'll discover new ways to leverage API data at your organization.
Concluding thoughts
Building vs buying an API analytics solution can be an overwhelming process, but the best companies get the most ROI when a a methodology is applied like above.
Sometimes it's recommended you try both. After all, building a solution may take 6 or 12 months but a purchased solution may take only a few hours to set up. In this case, it makes sense to purchase first, even if shorter contract to have something up and running while your company looks into what it takes to build.
The awesome thing about today's SaaS based solutions is you don't need to commit multiple years using a product. Purchase a solution, learn how the product works, and then go build it after seeing what features your team uses the most and what they don't use.
This article was written by Moesif founder and CEO Derric Gilling for the Moesif blog.
Looking for a complete API analytics solution? Check out Moesif
