Ask HN: How do you handle ultra power users? | Hacker News Reader

Ask HN: How do you handle ultra power users?

2 pointsbraden-lk4 comments

I operate a small knowledge management app for people that play tabletop RPGs. It's a wiki/mapping tool for keeping fantasy worlds organized. It's a subscription-based, collaborative, mostly-local-first app that runs in the browser. Shareability and collaboration is a fundamental conceit of the application.

I adore my users and am thankful for their business, but <1% of them produce ENORMOUS amounts of data. Tens of thousands of pages of text, millions of words, 1000x or more of the average user. I've chatted with these users and they're 100% legit; they're just prolific writers, or like copy pasting lots of content into their projects.

These projects push my application to the absolute limits. Because of these projects, for every feature I make, I must consider the extreme scenario, because someone comes along and pushes the feature to 1000x what I thought was possible. It certainly makes me think about algorithmic complexity every day.

Engineering-wise: sure, make the app more performant. But as a solo dev with a business to run, every product decision is a tradeoff, and performance improvements for 30 or so users suck away a lot of time from core product dev and marketing. Of course, I'll continue to improve the application, but if I set out to make it perfectly performant, I wouldn't have time for anything else.

From a product experience perspective, how do you handle super users? Should I just put my foot down at some point and say "no, actually here's hard limits X, Y, and Z"? Or just suck it up? Or design the product in a way that subtly discourages power-use? Rewrite the whole app in Rust? (Joking.) Obviously I want to make the app work for everyone that wants to use it, but I have to be realistic about my hours in a day. These users are great at surfacing bugs that would've affected everyone eventually, but some bugs are unique to "extreme power-use", especially with an imperfect host like the Browser.

> how do you handle super users?

You did not indicate whether this is a "free for use" app. or a paid app. The answer differs depending upon this fact.

> It certainly makes me think about algorithmic complexity every day.

Realistically you should be thinking about this anyway to some extent for anything much beyond quick one-off's to get a sub-task done in a larger task.

> Should I just put my foot down at some point and say "no, actually here's hard limits X, Y, and Z"?

My opinion, no. It would be fine to say something like "above X amount, you (may|will) find performance may be reduced" but don't add hard limits.

> Or just suck it up?

Are the users paying for the app? If so, then generally you will likely want to do so, otherwise you'll likely lose your best users.

Is the app free for use -- if yes then also feel free to say "yes, that amount of usage is going to cause problems, I'll work on it when I can, but 'real life' means I have little time to do so..."

> These users are great at surfacing bugs that would've affected everyone eventually,

Which is one big reason not to alienate them with things such as "no more than 1000 X's allowed". Most of them should be understanding of "no time right now for fixing that, it's on the list" (provided the app's free). If the users are paying, that's a different story.

Another option you might consider, in the "pay" scenario, is a somewhat higher cost for extreme usage situations to help cover your time investment in supporting those extreme usage situations.

Everyone's paying. We have a 14-day free trial, but otherwise don't really jam with the freemium thing. Gets too overwhelming in the B2C space.

I've updated the post to include that it's paid.

> My opinion, no. It would be fine to say something like "above X amount, you (may|will) find performance may be reduced" but don't add hard limits.

Makes sense, and in general has been what I've been doing. I just feel bad not being able to solve everyone's problems. Our only hard limit is "if one of your documents is >1MB of text, something has gone terribly wrong."

Have you considered limits with degraded experience? For example you might have a map with real-time-synced pop-up annotations, and someone puts too much stuff in there, and things gets too slow.

So you add the rule that text over X KB should be hosted elsewhere, and your nice real-time-map only gets a link to it - and that "elsewhere" is much simpler. Maybe it's a wiki page without collaborative editing support. Or as a more extreme version, you have to compose everything on your computer and upload a whole .txt file at once. Something that would be relatively simple for you to implement.

This way huge-text users would still be able to work, albeit with more effort... and yet everyone else would be able to enjoy fast experience.

I'd say hard limits, the ROI of those users makes it uneconomical to support them.

Reply on news.ycombinator.com