Why this guide exists
You’ve asked for product analytics — to track usage, highlight drop-offs, improve feature adoption, or just make better product decisions.
And someone (smart) says:
“We don’t need a new tool for that — we can just build it.”
This guide is here to help you respond. Not with confrontation, but with clarity.
Because while a single query might be easy, a reliable analytics platform is anything but.
Step 1: Acknowledge the Instinct
Always begin by validating the intent.
“Totally — if it’s just a one-off, that might be faster for us to build.”
“Yeah, I know we’ve got the talent to do this in-house.”
This shows you’re not against internal builds. You’re just here to surface the full picture.
Step 2: Clarify What’s Actually Being Asked
Now shift the conversation. It’s not about whether we can build a query — it’s about what happens after we do.
Use this framing:
“Right now it’s one query. But is that all we need?”
“What happens when someone else wants a slightly different version?”
“Are we going to version and maintain multiple queries per team or feature?”
“What happens when the product changes — do we update the metrics?”
“Are we building infrastructure for just this question, or for all future ones too?”
You’re helping everyone recognize that analytics isn’t a one-time thing — it’s a living, evolving part of the product.
Step 3: Make the Hidden Work Visible
Here’s where you outline what DIY analytics really involves. You can drop this in as a set of guiding questions, or adapt to your voice:
Data Engineering & Pipelines
Where’s the data coming from? Segment? RudderStack? In-app SDKs?
Are we doing custom ingestion? How will we manage volume spikes?
Are we transforming the data before it hits the warehouse?
What’s the plan for schema evolution?
Analytics Experience
Will this live in a BI tool (Looker, Metabase)? Do all teams have access?
Are we building dashboards just for ourselves — or for customer success? marketing? sales?
What’s the metric definition process? Do we version metrics?
Is this just a dashboard — or something teams will trust and reuse?
Integration Complexity
Do we want this data to show up in Zendesk? Intercom? Salesforce? Jira?
→ If so:How will we integrate securely with those platforms?
How are we handling token storage and rotation?
What happens if an API limit is hit or an integration fails silently?
Security, Privacy, and Access
Is any of this data sensitive (PII, billing, support interactions)?
Who controls access to these metrics?
Will these tools be SOC 2-compliant? Can we audit access?
Operational Ownership
Who owns the dashboards long-term?
When metrics need updating — who’s responsible?
Will this require a dedicated on-call or alerting system?
Are we okay with a single developer being the sole expert?
Cost (Now and Later)
What’s the infra cost for hosting the data and serving the dashboards?
Are we paying for warehouse compute or storage we’re not using?
What’s the cost if the system goes down before a board meeting?
Step 4: Suggest a Broader Framing
Now that the full scope is on the table, open up the options.
You don’t have to sell — just show that there’s another way:
“I wonder if this is less about one report and more about having a consistent source of product truth across teams."
“Feels like this might be better served by a platform — something that’s built for ongoing change.”
If they’re still leaning DIY, that’s fine. You’ve done your job by clarifying the real ask.
Optional: Share the Diagram
A visual can help — especially if you want to show just how complex this gets when it grows beyond the first dashboard.
Think of the inputs and outputs you may need. You can create your own diagram or share this one into a Slack thread, doc, Confluence or Notion page:
Final Word
When engineers say, “We can build that,” they’re usually right.
But “that” is rarely just a query. It’s ingestion, transformation, documentation, dashboarding, alerting, security, integration, and maintenance.
Use this guide to explore what “build” really means — and whether it’s worth the cost.