I’ve never met someone who built a dashboard in less time or money than they expected, regardless of how many times they’ve built other analytics features. Customer-facing dashboards have a way of becoming more complicated than expected to implement and to maintain over time. With our experience building dashboards at SaaS companies and with our clients at Verb we thought it would be helpful to share some key points to think about while performing your build vs. buy analysis. While we’re partial to a buy approach, it’s important to think through your options for your unique use case.
There are three types of costs that you’ll need to think about when estimating the true cost of dashboards.
The most obvious cost is labor – engineering, design, and product, to name a few. Dashboards require specific engineering and analytical skills like data engineers, architects, and data scientists. We often ask our teams to take on new skills which is applaudable but we have to take into account the time to learn and relearn new skills. We also have to consider the speed at which our teams can work when learning something new.
The cost of materials is highly dependent on your architecture but a good dashboard needs a centralized data store that is not the production database (a data lake), a pipeline tool to help transform and move data quickly, and a data warehouse to pre-aggregate your data. It can be incredibly difficult to estimate the costs you will incur with each of these tools due to the nature of customer-facing dashboards. You won’t have a good sense of peak usage of dashboards or simultaneous use across your customers.Most of these tools are consumption-based which make it difficult to limit expenses as well.
I think this is the hardest cost to estimate because most calculations for the value of a feature are subjective. Comparing a set of features that your team can build in the same amount of time as a dashboard will take to implement relies on the value that the features create for your business and your customers. The calculation will be unique to your business because every business’s value proposition is different so your product strategy must align with that.
The second part of the opportunity cost that many of us forget to include is the cost of maintenance. Dashboards have a lot of dependencies which mean that new features will often require additional updates to the existing dashboard. For example, if there is a schema change, the data that supports dashboards may need to be updated as part of the feature release. This process slows down feature releases because the level of effort expands as dashboards are added to the system. Without dashboards, teams have less dependencies to worry about and can move faster.
Phases of Expenses
The three costs are relatively easy to identify but they occur in three phases of product development. Estimating these is the most important part of any build analysis. It’s incredibly difficult to fully estimate the cost and we’re not advocating you try. However, it is important to go into a project with eyes wide open and realistic expectations.
The implementation phase is the largest cost and probably the easiest to estimate. An important part of the implementation phase that is often forgotten is performance testing. While this doesn’t add a lot of time to the initial project it can save a lot of time down the road. We suggest that you do your best to limit cutting corners, more so than you might typically do on a normal product feature. On a dashboard it can really come back to haunt you.
In our research we found that the average dashboard took about 6 months to release – from start to finish. Some smaller dashboards were released in about 3 months and the more sophisticated ones took up to a year to roll out.
Maintenance & Scaling
In most build-analysis, teams underestimate the cost of ongoing maintenance if they even include it in their analysis. The material costs of maintenance and scaling are the monthly fees for the components and infrastructure you’re using. As mentioned previously, it can be difficult to estimate consumption-based expenses for customer-facing dashboards because it’s difficult to predict user behavior.
Performance tuning is also critical, but often ignored until it’s too late. Dashboards tend to get slower over time as platforms and data grow. Without prioritizing the performance, your user-experience and system will suffer. Every feature you add will increase expenses because the dashboard will likely need adjustments with each new feature – even if the end-user isn’t aware. These additional features cost extra time and engineering hours, which as we mentioned earlier, are oftentimes one of your most expensive deficits.
Iteration and Enhancement
An iterative approach to dashboards is rarely taken because of the level of effort to implement dashboards. It is hard to implement tests but still necessary to create an experience that your customers want. The more interesting and relevant data that you can provide your customers, the happier they will be.
Analytics feature enhancements are nice to have but keeping your dashboard’s data accurate is critical for your business. As new features are added and schemas shift you will need to re-work the data that supports your dashboards. When working on new features, dashboards should be included in the dependency planning that your team completes.
Customer-facing dashboards are neither easy nor cheap to build, but they are incredibly useful and in many cases necessary for your platform and customers. They can be the edge that pushes you past the competition, but they can also slow down development – limiting your nimbleness to respond quickly. It’s important to understand the costs that you’ll incur through the implementation, maintenance, and scaling of a dashboard before you decide how to create your next dashboard.