Ask HN: Did you build or buy your customer analytics? | Hacker News Reader

Ask HN: Did you build or buy your customer analytics?

2 pointslane_g3 comments

We're building an embedded analytics tool for SaaS teams that want to give users self-serve dashboards without spending weeks on dev time or budget.

My last startup grew to 50k+ monthly users and we ended up outsourcing a clunky analytics portal that cost over $4k and took 8 weeks to launch. It was frustrating to maintain and never felt like part of our product.

We're trying to solve that pain for others, especially smaller teams without extensive development resources.

Hoping to hear from folks who’ve had to ship customer-facing analytics:

Did you build in-house or use a tool (like Explo, Luzmo, etc.)? Why?

What were the biggest tradeoffs or frustrations?

How did you handle multi-tenancy, branding, or performance?

What do your users actually expect from analytics inside your product?

What's still missing from current solutions?

View on HN

I’ve worked on customer-facing analytics at two companies. A large organization where we used Tableau, and a startup where we used Metabase.

At the larger company, we explored moving off Tableau to save on license costs. We started prototyping in-house dashboards using React with libraries like D3.js, Visx, and Recharts. But it quickly became clear it was too much effort to get something stable and usable, so we dropped the project.

That was the core frustration. We wanted analytics to feel native to our product, but kept hitting a tradeoff. Tableau was fast to stand up (the team already knew it) but never felt like our product. Building in-house gave us the control and flexibility we wanted, but the dev lift was too high and our data team wasn’t set up for frontend work.

At the startup, we didn’t run into performance issues. But at the larger org, we started having performance issues. We migrated from Redshift to Snowflake and rebuilt our row-level security model to only query scoped data. We also limited historical ranges to keep things performant.

The use cases were different too. At the large org, users just needed to view a handful of dashboards inside our app. At the startup, we wanted customers to dig in, explore their data, and build their own charts.

What still feels missing is giving data teams true ownership of the embedded experience. In practice, software engineers usually don’t want to deal with analytics. They want to focus on product work. But embedding, styling, and access control often require engineering help. I think that gap is still real today. Maybe as analytics engineers become more full stack, that handoff will get easier, but right now it’s still a source of friction imo.

Thanks for taking time to share this insight. This is helpful to hear.

Added context: Sending this from the trenches and looking for validation and feedback on our product called Lemonado (https://app.lemonado.io/signup) - it's free to try. Here's the full post (https://lemonado.io/blog/hn).

Reply on news.ycombinator.com