One way to work through this would be to provide viewer vs collaborator user types - but ofc a viewer wouldn't be able to actually create tickets. The true goal is to build a system where everyone is productive as soon as they join, where a $5-$8 cost seems incremental, vs the work the system is able to augment for a full-time developer, business person or a contractor. This is why we're designing Tara to initially be an interface in terms of user interactions, but over time, to augment work as it happens. We've started down this path with effort predictions, sprint loads and automation of statuses.

We’ve explored ways to handle this. One of the things we’ve considered is metered billing where you only pay for the time the seat is used. It’s very similar to Github seat model but probably closer to slacks billing system.

Other explorations we did were around finer grained permissions or a collaborator vs assignee. The reason the industry itself is geared towards seats based plans in the is to drive better revenue predictability and handle cost variability between free and paid users better but we’re seeing more and more creative changes to sass billing models.

Primarily, you just look at this as a cost of the person's salary.

$10 / person as a standalone fee seems very different than...

$X,000 / month salary + benefits + $10 / month for a service that helps them get more done with their time that you're paying for.

Totally agree about guest contributors though. IMO ClickUp.com has the best pricing model of the bunch for this type of thing.

Why not charge based on typical "packages" containing a certain number of interactions with the service?

Maybe you can use generic usernames like freelancer01@mycorp.com and only change the display name e.g. Jim Smith <freelancer01@mycorp.com> in January, Sarah Lee <freelancer01@mycorp.com> in February?