TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

3 点作者 tagspace大约 2 年前
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?

3 条评论

warrenm大约 2 年前
fwiw ... you <i>might</i> be &quot;successful&quot; doing what you&#x27;re proposing (if you choose a tiny feature set, and discard everything else everyone asks you for)<p>...but the <i>reason</i> &quot;out-of-the-box solutions&quot; exist is because other folks have <i>already</i> spent the millions of developer hours, user feedback, etc to get it <i>working</i> :)<p>Several years ago I worked for a company (filled with seasoned, smart, great devs) that tried to in-house their own reporting tool<p>They quit and migrated to Crystal Reports because integrating an existing tool was worlds cheaper&#x2F;faster than trying to do it all themselves<p>Later they migrated to BIRT because of CR limitations<p>And did another migration a couple years after that (I forget now to what tool)<p>The only drawback from a end-user perspective of those migrations were that reports couldn&#x27;t be automigrated between reporting platforms
评论 #35860935 未加载
danieka大约 2 年前
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.<p>[1] <a href="https:&#x2F;&#x2F;cube.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cube.dev&#x2F;</a>
评论 #35871259 未加载
hjkm大约 2 年前
It&#x27;s the requests for follow-up questions that can make building and maintaining your own version tricky.