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

3 pointstagspace2y ago6 comments

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?

6 comments

warrenm2y ago

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

tagspaceOP2y ago

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.

warrenm2y ago

It may be worth investing your time in skinning/theming whatever reporting/search tool you decide to use :)

danieka2y ago

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/

e1g2y ago

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

hjkm2y ago

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

j / k navigate · click thread line to collapse

6 comments

warrenm2y ago

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

tagspaceOP2y ago

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.

warrenm2y ago

It may be worth investing your time in skinning/theming whatever reporting/search tool you decide to use :)

danieka2y ago

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/

e1g2y ago

+1, we use it and love it.

hjkm2y ago

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

j / k navigate · click thread line to collapse