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:
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.
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.
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.
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.
Here are a few things software companies should consider before partnering with a BI developer:
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.
Here’s one thing we can promise you, contact us and let’s discuss your requirements and we’ll give you an honest assessment if Yurbi might or might not be a good buy to save you from building.