[esafak]

> But... I don't truly know what my users want. There is no telemetry of any kind in Luxury Yacht. I like being able to say that, but it means I have no idea how many people are using it, or how they're using it. I don't know what features are the most important to other people.

So add telemetry and a request tracker like https://www.productboard.com/. This is not a solo vs team thing.

[johnj-hn]

I don't want to add telemetry. And I think this is where the solo vs team thing matters. I can just say "no telemetry" and I don't need to argue with anyone about it. I make the decision and live with the consequence.

I don't really need to know how many people use the app. It would be cool to know, but not necessary.

If someone wants a feature, or a fix, they can open an issue.

[satvikpendem]

Then that's not really a con if you refuse to fix the problem you yourself mentioned. It's like saying, I'm not getting enough iron in my diet, and someone suggests eating foods with more iron, and then saying I don't want to. Okay, then don't bring it up in the first place.

[sublinear]

Most projects don't need telemetry. They need better logs.

On the backend... Why wouldn't you log every request that hits your server, and why wouldn't you already know what those requests mean? Why would you let your frontend make direct requests to any other server when you can just proxy it yourself and maintain control?

On the frontend... What's so hard about wrapping all your event listeners and periodically sending those logs back to your server?

That's not even scratching the surface, but even something this simple and easy to implement is already miles ahead of most free-tier telemetry offerings, and you retain full control.

[efromvt]

If you don't have a backend, then it's all telemetry, right? And backend logs don't capture a lot of the UX side of things - how a call got triggered, from where, etc (which yeah you can start to instrument, but then that's telemetry).

[skydhash]

I would say: Never solve problems for people you don’t know. First solve for yourself. Then solve for people in your community. Someone reaching out with a suggestion is more valuable than bazillion of analytics.

[efromvt]

Very much in agreement with this but especially on the UX side I find that 'what is intuitive to me' is not universal because you come with a bunch of contextual priors you can't clear. I wish there was more tooling focused on how to use tools to expand customer empathy past what you can directly experience; that's an inherently audience-limiting approach.

(I admire PMs that can cross that chasm; it's also why they're often bad at infra tooling, because you can just short-circuit the empathy).

[sublinear]

I agree, but my point was there are too many sedimentary layers of vocabulary put there by the marketing and checklist people. If they didn't obscure and paywall basic functionality, they wouldn't have a business.

In my example (assuming a web view, but similar mechanisms exist for native), the event wrapper would give a lot of context if the event target string is logged. That will contain the query selector. It should already be best practice to have unique and human-readable IDs on every interactive element in the DOM anyway.

Sloppy frontend builds are a topic for another time, though.

If there's no server, you should at least still proxy these logs to your own domain. The vast majority of sites are just pasting a generated script tag or cluttering their build. The "right way" is just as easy.