HACKER Q&A
📣 tagspace

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


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 Accepted Answer ✓
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


👤 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/


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