Like many product owners, I have frequently been faced with the decision to build or buy when I was developing and launching products. I still vividly recall the inception of my first product, AppTRAX. Launched in late 2010, it was a database of the most popular mobile applications on the top mobile platforms. The goal was to provide ongoing intelligence to those looking to launch their own app initiatives—wireless carriers, handset manufacturers, content owners, and application developers.
While billions of mobile apps have been downloaded today, at the time, the market was still developing and it was unclear if the product would be successful. So I had to find a way to collect, aggregate, and share the data with practically no budget.
As I began investigating options I found several web-scraping services with a range of business models. But my expertise was not in web-scraping, data aggregation, or data sharing, which further complicated my decisions. I came up with three main options.
1. Use open-source solutions. My initial inclination was to go open source. There were many tools available, which made this option very appealing. However, I found the reliability of these solutions less than adequate. Some would be updated regularly, others not for months (or years). As the web matured and companies began defending their sites, these tools did not have the R&D to penetrate those defenses. Ultimately they weren’t easy enough to use, not reliable enough to ensure they worked every time, and the cost savings from using them was far less important than having a robust product offering.
2. Have someone do it for me. At the time, there were many companies that offered full-service solutions for web scraping. For a (high) fee they would scope the project, create the searching agents (which they would own), and send me the data. This was appealing since it required little effort on our part. But it was very expensive, and it prohibited me from making changes on the fly as data evolved—and I wouldn’t own any IP other than the data itself.
3. Buy a web-scraping platform. In the end, the best solution was to find an affordable, easy(ish) tool that I could learn to use quickly but was supported by experts and guaranteed to be updated regularly. This is the route I took when I chose Mozenda—a relationship that is still ongoing at my former employer to this day (I’m even featured on their website). This approach provided me with a low-cost option to get started with, it gave me control to make changes on the fly, and it guaranteed that as technology changed, the software would be updated without a ton of effort on my part.
Looking back, I know I made the correct decision on which path to choose. Since that time, many of the open-source solutions have disappeared. Failure of those companies or technologies would have left me in a lurch once the product went GA and customers were relying on data regularly. On the other hand, buying a complete solution would have made the price of the product so high it would have been difficult to gain market momentum. Even if we did, our ROI would have been low. Instead, the path we chose allowed us to get to market quickly, create valuable unique IP, get a significant return on investment, and build a thriving business.
Now, many years later I hear Logi’s prospects and customers regularly talk about facing a similar decision when it comes to analytics. They wonder if they should use components or buy a complete solution. I would argue that the middle road is the best option—at Logi, we call this an analytics development platform. It allows for the flexibility of building, the assurances of being backed by a customer-centric company, and a price that makes ROI real.
If you’re currently debating the build or buy conundrum when it comes to embedded analytics for your application, start a free trial of Logi’s analytics development platform to get the best of both worlds.