Ask HN: When building in-app reporting for your customers, what can go wrong?

[tagspace]

We want to build in-app reporting/analytics for our customers, but we don't want to use an out-of-the-box solution as we care a lot about look and feel. Has anybody had success in building in-app reporting themselves without it becoming a mess (never ending list of new features)? Any learnings you can share?

[warrenm]

fwiw ... you might be "successful" doing what you're proposing (if you choose a tiny feature set, and discard everything else everyone asks you for)

...but the reason "out-of-the-box solutions" exist is because other folks have already spent the millions of developer hours, user feedback, etc to get it working :)

Several years ago I worked for a company (filled with seasoned, smart, great devs) that tried to in-house their own reporting tool

They quit and migrated to Crystal Reports because integrating an existing tool was worlds cheaper/faster than trying to do it all themselves

Later they migrated to BIRT because of CR limitations

And did another migration a couple years after that (I forget now to what tool)

The only drawback from a end-user perspective of those migrations were that reports couldn't be automigrated between reporting platforms

[tagspace]

Thanks @warrenm. That makes a lot of sense. The problem is that that feels like we'll have to throw away the "looks like a nicely integrated part of our platform' requirement.

[danieka]

It sounds like you only want to build the frontend yourselves? You could take a look at Cube[1] which will probably work fine as a backend for your in-app reporting.

[1] https://cube.dev/

[e1g]

+1, we use it and love it.

Cube is “headless BI”, which means you still have your own widgets at the front lend, and existing DB at the backend, and Cube sits in the middle helping you combine/filter/group/stat across your tables and other data sources.

[hjkm]

It's the requests for follow-up questions that can make building and maintaining your own version tricky.