When it comes to embedding dashboards and reports, should you build or buy? Do you take your resources and build a solution, or do you go out and partner with a BI provider? For many of our partners, this is an important question that needs to be addressed sooner than later.
There are two common scenarios regarding “Buy vs. Build” that we see in the industry.
The first involves an established software company. Chances are they’ve already taken the time to build a core set of reports and dashboards inside their product. But the reports that they create are somewhat static and hard to alter. They’re inflexible. Plus, users demand more access to their data, and more abilities to data mine and query data themselves. The current reporting method doesn’t cut it for the customer.
The other scenario typically involves a new company that’s just starting out. They know the value of reporting—it’s important to their customers—and they realize it might be a smart (and affordable) decision not to tackle and build a reporting infrastructure on their own, but to go out and partner with a BI developer directly. But they need a partner who doesn’t break the bank.
In general, in either case, the best path is to partner. Let’s take a look at three reasons why:
1. Embedding dashboards takes time and focus
One of the biggest reasons to partner with a BI developer is building the reporting and dashboards themselves takes away from the development time of your core product.
Consider this: businesses that venture into building their own dashboard software generally have a lot of features they want to implement that will add value while distinguishing themselves from the competition.
But reporting—while extremely important to the customer—is just reporting. At the end of the day, you don’t want to become a company that’s just building reporting tools.
At first glance, creating dashboard and reporting software seems easy. You have a good set of requirements of what your customers are looking for, and those requirements are relatively simple to implement. But eventually, your customers are going to demand more features. More use cases will arise, more scenarios you hadn’t factored in will develop, and more implications regarding security will occur.
What you thought was going to be “just a few development sprints” is now turning into a fulltime development responsibility. And it’s not just adding new features that are consuming time, but returning to fix the ones that are already in place (we’re a development company just like you, 99 bugs on the wall, fix one, pass it around, 107 bugs on the wall ).
Meanwhile, your customers aren’t happy with what you’re delivering, and (more importantly) you’ve divided your interests away from the core roadmap of your products.
This is why businesses should look to partnering—so as not to divert their resources from the core purpose of their product.
2. Speed to market
Another big reason to buy rather than build when embedding dashboards is speed to market.
Even if you have the resources to build dashboards and reports, it’s not going to take a couple weeks’ worth of development time. It’s not going to take a couple months, either. It’s going to take a lot of time to get this out (done right).
Shortening the development time means sacrificing certain powers and features which could then result in delivering a set of hard-coded reports and dashboards—something most customers are not interested in. If you really want to invest in your DIY dashboard and develop a full ad-hoc self-service BI, then you’re essentially replicating what BI companies do for a living.
On the other hand, plugging mature BI software into your application will drastically improve the speed in which you meet your customers’ requirements, make your customers happy, and turn your new product into a very robust piece of software. Compare that to developing the software yourself, which could take a very long time.
3. Embedding Dashboards and reporting software requires continuous support
Making an in-house dashboard and reporting application is not a one-time operation.
Your developers have to continue to support and maintain it. If the requirements change then your development team will need to go back and look at it again. This means a whole new set of reports, metrics, and dashboards will need to be developed all over again.
Basically, if your developers build it, they’re always going to be the mechanic.
One of the biggest benefits we hear our partners talk about when they plug in technology like Yurbi is that, after the initial integration is developed, any time they have a new report or dashboard requirement to add they don’t have to ask their developers. They can go to a support team or product management team, or any kind of non-technical or non-developer oriented resource, and have them build that requirement without needing to allocate developer resources again.
When building in-house software makes sense
Now, while we generally think it’s in a company’s best interest to buy rather than build when embedding dashboards, but there are certain situations where building makes sense.
The technology has to be compatible. BI software has to easily integrate into the server and development infrastructure. If a company has everything hosted on Heroku, then the dashboard technology probably should run on Heroku as well. If you’re primarily on-premise, then they probably need software that is easy to deploy. If you leverage Microsoft and .Net then you need a BI solution compatible with .net architecture too.
The pricing model will change based on scale. The price of any given BI software can drastically change as a company grows and expands. While it may be affordable for a company to buy a license or subscription when they’re just setting out if they scale in size—if they grow ten times their current size, say—then how much are they going to be paying for embedding dashboards at that point? Is it going to cost so much that it’s unreasonable? Could it become so expensive that they’d be better off building it themselves? The price tag that comes with expanding is best avoided from the beginning (rip and replace is expensive and tough).
No direct control of the partner. If you have enhancement requests, or if you need things done to the technology in order to make it work better, it’s not like you can assign one of your developers and say, “hey, go change our partner’s source code.” You won’t have access to the product in that way. You have to work through the partner’s environment.From that perspective, you need to understand how fast they’re going to be able to make changes for you, and how open to making changes they are. If you partner with one of the bigger BI companies in the industry, it’s going to be extremely hard for them to make changes for you. They have longer roadmaps and development cycles. But if you go with a mature BI company that’s smaller, than you’ll have more influence to adjust their roadmap or receive faster support and service.
We think it’s pretty smart for companies to partner for embedding dashboards under the right circumstances. It could be a win-win across the board because you’ll have speed to market and powerful analytic results for customers without having to allocate as much of your development resources to do that. You can focus on the most important aspects of growing your products, services, and business while your BI provider handles the technical aspects of your software.
Is buying for everyone? Not necessarily. As we mentioned, there are a couple things to consider before partnering with a BI software vendor. If you expect significant growth in the near future, or you want to make hands-on, custom adjustments according to your customers’ requirements, then building might be a better option.