@pinoaffe Ah, right - that's going to be dependent on the type of software, usually, but a good first pass is "hyperoptimize it for non-commercial use where no money changes hands"; like, deliberately build things without room for a billing mechanism or customer management, for example (eg. no ability to suspend an account for non-payment).

Another good one (though it requires more care to not introduce eg. unintended accessibility issues) is to design around a rigid way of using the system, especially around reporting.

Corporate users often need the software to work in very specific ways because "the manager said they want a report in such-and-such format" regardless of whether that actually makes sense, and every such reported issue that you can answer with "we have no intention of supporting this, _____ should be good enough" is a win.

It does take some experience, but after a while you'll learn to spot the complaints and feature requests that are obviously for corporate use, vs. those of individuals or collectives. "Needs a feature or change because someone else told them to, rather than because it solves a clear problem" is the major red flag.

@pinoaffe (Note that they usually won't *tell* you that someone else told them to; they will just insist that they need the feature and be incredibly vague as to why, or come up with an explanation/usecase that doesn't make sense)

@joepie91 ah yes, thanks!