For one of my projects, I was asked to submit a portfolio sample, so I built a dashboard using Google Apps Script (GAS).
Here’s what it looks like:
If you’re curious, you can check out the live version here:
I have experience building dashboards with BI tools and lightweight web apps using Python + Flask, but this was my first time building one with GAS.
Since this is a relatively niche use case, I thought I’d share my findings.
When Does It Make Sense to Build a Dashboard with GAS?
Google Sheets already offers charting capabilities, and BI tools can make dashboard creation quite straightforward.
Still, there are situations where using GAS makes sense, such as:
- Adding functionality not available in standard features
- Creating interactive UI components
- Integrating with other Google services
- Managing the dashboard in code form
- Keeping costs low
- Fetching data from external services
In other words: a fully automated, customizable dashboard that updates itself, without the licensing cost of BI tools.
Spreadsheets and BI tools trade off flexibility for ease of use, and dashboard projects often balance customization against development/maintenance costs.
Here’s my personal “feature matrix” comparing some common options:
| Item | Google Sheets | BI Tools | GAS | Scratch Development |
|---|---|---|---|---|
| Development Barrier | Excellent | Good | Fair | Poor |
| Customizability | Poor | Fair | Good | Excellent |
| Data Volume Handling | Fair | Good | Poor | Excellent |
| Development Speed | Excellent | Good | Fair | Poor |
| Additional Cost | Excellent | Fair | Excellent | Poor |
| Maintenance Load | Poor | Fair | Good | Good |
For small organizations such as startups or SMEs, where the dataset isn’t huge, there’s no budget for BI tools or custom apps, and spreadsheet-based manual management is also impractical, GAS dashboards can be a viable middle ground.
Dashboard Design Choices
For this project, I built the dashboard as a web app and used Plotly for rendering.
Why Plotly? I was already comfortable with it from data analysis projects, and since this was a sample, I wanted to highlight interactivity and responsiveness.
That said, Plotly isn’t the most common choice for GAS dashboards.
If you’re building a web app dashboard with GAS, the more typical approach is Google Charts Service (Charts API).
It’s built-in, renders on the server side (reducing browser load), requires no extra libraries, and is straightforward to use with methods like Charts.newAreaChart() or Charts.newLineChart().
Plotly, by contrast, is loaded via CDN through the HTML Service and rendered in the browser.
It offers rich features—hover tooltips, animations, responsive layouts—out of the box, but it requires HTML/CSS/JavaScript knowledge and more complex setup.
Heavy datasets can cause browser freezes.
Also, remember GAS’s limitations: a maximum execution time of 6 minutes and limited memory.
With datasets in the 100k+ range, it’s more practical to preprocess with BigQuery or switch to a BI tool.
In my case, even with ~2,000 rows, I noticed a few seconds of lag during aggregation. It’s borderline acceptable but not ideal UX. For a sample, I decided that was fine.
About the Sample Data
At first, I looked for government datasets, but I needed something that wasn’t too large yet still rich enough for graphing. Overly simple datasets make poor demos, and I didn’t want to spend too much time on data preparation.
I ended up using Kaggle’s Retail Fashion Boutique Data Sales Analytics 2025.
Kaggle datasets are well-documented, tagged, and even provide quick visual previews—very convenient.
However, as is often the case with competition datasets, the data can be biased; here, many records were clustered in a specific month. A quick exploratory check beforehand is always a good idea.
Do You Even Need a Dashboard?
This might sound counterintuitive, but before building a dashboard, you should first ask:
- Who will use it?
- What information will lead to actionable insights?
- Why did “dashboard” become the chosen solution?
Without answering these, you risk creating something no one uses but still requires ongoing maintenance.
In many cases, a dashboard just centralizes metrics that are already calculated elsewhere.
If the goal is simply to reduce reporting workload, a plain text summary could be cheaper and faster.
And when you aggregate metrics, they often become more abstract, meaning you still have to drill down into the raw data.
That’s why I prefer to see dashboards as portal sites to distributed datasets, rather than as the final stop for analysis.
That said, dashboards can feel fresh and engaging for users, and they can automate repetitive reporting tasks.
The key for developers is to maintain a critical eye: is this really the best solution for the problem at hand?
Top comments (0)