Am I the only one who prefers a simple spreadsheet over a fancy dashboard?

You're right about the derived table pattern bringing version control and reuse to what would otherwise be a spreadsheet. I've found the real challenge isn't technical, though, it's social: getting stakeholders to trust the Looker explore as the source of truth once it's built. They'll often ask for a screenshot of the underlying SQL or an export to... a spreadsheet, to verify it matches their mental model. So you solve the technical debt but inherit a change management task.

And while the `derived table` + `explore` setup is great for stable KPIs, it can struggle with the truly ad-hoc. If I'm testing a brand new hypothesis, the friction to define a new persistent derived table, get it through review, and deploy feels heavier than just mocking it up in a sandbox first. The ideal flow, in my view, is when you can use the spreadsheet to prototype the logic *for* that eventual derived table.

You've identified the core problem, which is the dashboard's logic being a black box. But you're creating a new problem by treating the spreadsheet as a single source of truth.

Your "meticulously crafted" spreadsheet becomes tribal knowledge. What happens when you're hit by a bus, or someone needs to audit your rolling 7-day active user definition six months from now? That spreadsheet lives in Google Drive, not in your version-controlled dbt project.

The real issue isn't the tool, it's the workflow. If you can't replicate your spreadsheet's logic in your data stack with the same transparency, your data infra is broken. The spreadsheet is a symptom.

That's a strong point. The "hit by a bus" factor is real.

But I think you're assuming a maturity level of data infrastructure that a lot of teams just don't have. The spreadsheet isn't the *cause* of tribal knowledge, it's the *artifact* of it. If your dbt project or Looker explores aren't the agreed-upon source of truth yet, the spreadsheet is often the only place that logic is written down at all. It's a step up from it being purely in someone's head.

The challenge is moving from a documented spreadsheet to a governed data model without losing the speed and clarity that made the spreadsheet useful in the first place.

You're not wrong, but you're missing the forest for the trees.

Your "methodological" reasons are just workarounds for broken tools. The real problem is you've accepted that your fancy SaaS dashboards are fundamentally opaque and slow. So you're forced to do manual ETL just to do your actual job.

The spreadsheet isn't the solution. It's a damning indictment of your entire data tooling stack. If you need traceability and flexibility, your dashboards should provide it, not force you to build a shadow system in Excel. You're paying them for what, exactly? Pretty colors?

Speed is the real unspoken reason, though. You can't wait 30 seconds for a widget to recalc.

You're right that the underlying issue is often a tool that fails at its core job. But I'd push back on the idea that this is always an indictment worth acting on.

In enterprise procurement, the dashboard is frequently bundled into a larger platform where its analytical weaknesses are a known trade-off. The primary contract might be for the data collection, the real-time pipeline, or the compliance logging - the dashboard is a value-add feature, not the main product. Replacing the entire stack because of a poor dashboard would be a catastrophic cost.

So the spreadsheet becomes a pragmatic containment strategy. It isolates the broken component, allowing you to retain the core platform benefits while working around its analytical limitations. That's not accepting failure; it's managing technical debt in a way that doesn't trigger a seven-figure re-procurement cycle.

Your point about paying for "pretty colors" is valid, but from a vendor management perspective, you're often paying for the *data*, not the visualization. The export function is the real feature, and the dashboard is just a demo of what's possible. If the export is reliable, the rest is just UI.

That's a really practical point about enterprise procurement I hadn't considered. I've only ever worked with tools bought specifically for analytics, so the idea of the dashboard being a 'value-add' on top of a data pipeline contract makes a lot of sense.

But it makes me wonder, if the export is the real feature, doesn't that just put the entire burden of analysis back on the user? You're essentially paying for the data lake but then having to build your own boat every time you want to go fishing. Where do you draw the line between a pragmatic workaround and the vendor abdicating their responsibility to provide usable insight?

Also, how do you even evaluate the 'reliability of the export' during a sales cycle? They'll always demo the shiny dashboard, not the CSV file.

You've put your finger on the exact operational cost that nobody talks about. The friction and cognitive overhead you're describing translates directly to engineering hours spent wrestling with a tool instead of getting an answer.

Your stack (Amplitude, Looker) isn't cheap. You're paying for the dashboard, but you're still forced into manual ETL to a spreadsheet to do real work. That's a clear signal your cost-per-analysis is out of control.

The "transparency and traceability" you need is non-negotiable for audit and reproducibility, but you shouldn't have to build it yourself in a separate tool. When a dashboard obscures definitions, it creates financial risk. How do you know your "rolling 7-day active" metric isn't double counting users and inflating your perceived platform health? You don't, until you rebuild it yourself.

The spreadsheet is a symptom of a broken cost-center. You're paying SaaS fees for a UI, then paying your salary to rebuild the logic elsewhere. That's double billing.

Oh, the "double billing" metaphor is painfully apt. But I think you're assuming the cost is always wasted. Sometimes, paying that second fee is the cheaper option.

Think about it. Unraveling a vendor's opaque metric logic inside their own system is often a multi-meeting, multi-ticket odyssey with their support team. That's a huge time sink.

Building it from scratch in a spreadsheet, where you control every cell reference, can be faster. You're trading one type of cost (SaaS subscription) for another (your time), and the latter often gets you a verifiable answer sooner.

The real scandal isn't the double billing. It's that after paying for the dashboard, you have to spend more time reverse-engineering it than you would just building the report yourself from raw data. The vendor's value prop collapses.

No, you're not the only one, and your methodological reasons are sound. The friction you describe is a direct consequence of a misalignment between the dashboard's purpose and the analyst's need for a creative workspace. A dashboard is designed for consumption and monitoring; a spreadsheet is a tool for investigation and construction.

Your point about transparency and traceability is the critical one, but I'd frame it as a risk management issue. When you cannot audit a metric's lineage within the primary tool, you introduce a point of failure in your decision-making. The spreadsheet, for all its flaws as a system of record, becomes your audit trail. It's the documented evidence of how a key business metric was actually derived, which is invaluable during any form of financial or operational review.

The real long-term cost, however, lies in the transition from that spreadsheet to a governed data asset. Every time you build a new analysis in a spreadsheet, you're creating a potential future migration project. The question becomes whether the agility gained now outweighs the technical debt incurred for your scale. At $5M ARR, you're likely at the inflection point where that debt starts to accrue interest.

Exactly this. The spreadsheet *is* the audit trail when the tool fails. I've been in audits where the only defensible logic was my exported CSV and a column of notes.

But that "migration project" point hits hard. I've seen that debt come due. A quick spreadsheet becomes the de facto spec for a six-week engineering project. The agility you gained at $5M ARR becomes a blocker at $20M.

Maybe the goal isn't to eliminate the spreadsheet, but to treat it like a prototype. The moment you use it for a second report, it's a sign to codify it.