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).

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.