[ddon]

Why startups don't try to break this charge per user per month thing? Would be great to have products which would charge like $10 a month for up to 5 users or so... why so greedy and charge 10 per user? So, if small team of 5..10 people, at $8 a month per user, is like $100 a month for single service. And if startup needs like 5..10 different services to pay, it becomes like a pretty good amount for paying for different services.

[gexla]

If you're actually employing 5 people then $100 is nothing for service which is central to your work. If it's 5 people not making money, then maybe you don't need a proprietary service.

[brightball]

This is the correct answer.

[saurik]

I guess if you assume that "small teams" are all working 100% on the one project... which isn't even slightly reasonable (hell: that isn't even reasonable for large teams). The per-user thing essentially means you are paying costs constantly for people who just need access to something as a contributor even though they are using it once a month. It is incredibly frustrating having to be like "ugh, I contracted with someone to work on some icons for my app, but now I have to pay for them to have a 'seat' on all of our project management tooling".

[iba99]

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.

[syed99]

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.

[brightball]

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.

[johschmitz]

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

[robertlagrant]

This sort of thing is pretty annoying to procure. Imagine you have 20 suppliers and they all have bespoke pricing arrangements, vs you have 20 suppliers, who each charge you X per active user per month.

[wiradikusuma]

Maybe you can use generic usernames like [e-mail] and only change the display name e.g. Jim Smith <[e-mail]> in January, Sarah Lee <[e-mail]> in February?

[syed99]

Hi ddon, one of the founders here. I personally do agree on flipping the pricing models to be more inclusive. We’ve tried our best to make them as cost effective as possible and even go as far as allowing unlimited users on a free plan.

When we were working on pricing, we looked into everything from compute costs per user, data storage per workspace, new feature development, marketing costs and much more over the span of time. We came up with our pricing based off those costs and hence on our lower plans we’re still under the price of similar tools.

We’d love to, in the future figure out more flexible ways to price our users but at the same time maintain the service and growing feature set. I can assure you that we definitely gave having a Spotify family plan like pricing model a thought. In the mean time we are working with startups to accommodate their needs as they move into paid plans by offering discounts on long term commitments, we’re always open to discussions with our users and helping them stay empowered on our platform.

[jillesvangurp]

Very simple; at the prices you cite, the largest charge is the one you forgot about: people hours needed to maintain and setup these services. 100$ sounds like a lot but it's only 1-2 hours of development time per month; less if you are in a competitive market. And lets face it, it's never just 1 hour per month. Just spending a week or so setting this stuff up could fund years of SAAS bills potentially in terms of time spent. And a week is not a lot.

You also get this sunk cost fallacy where you basically keep on poring in more time (and money) because you've already invested so much. Self hosted commodity services only makes sense these days if you have too much money or very specific needs that you are willing to pay for. Even at their premium pricing, they are a pretty good value proposition for most companies.

Asana on the freemium layer is still pretty good value and an easy upgrade once your team grows. Same for github. We pay for neither. Github comes with Github actions too with lots of free CI minutes per month. The Slack freemium layer is pretty decent as well (more than enough for any startup). I'd consider paying for all of the above if I had to because these products are kind of nice to use as well. But I don't. 0$ / month is a pretty hard price to beat.

But even at hundreds per month, self hosting would still cost more and deliver less.

[syed99]

I guess from the other sub thread below Self Hosting takes away alot of the liabilities of operating the software when you're small, atleast in the a very litigious US and Europe. Larger incumbents eventually have been moving away from that self hosted model to provide consistent service or layer on professional services for those that can afford it.

[manigandham]

Offering a similar product at lower pricing is usually the worst-way to compete unless it's a major disruption (free, different business model, etc). You might help a few small customers but you'll end up missing on most of the revenue that your competitors are capturing.

While bills do add up, you should only be paying for services if they're delivering more value then the price you're paying.

[syed99]

That’s how we see it too. We didn’t underprice it to simply compete, it’s a mix of how the actual tech is built and how we can keep our net costs per user low. We’re just curious and love to hear how users perceive pricing and want to facilitate a conversation. The major value prop here is around automation; reducing engineering time in manual status updates in tickets and high value actions like assignment or effort prediction.

[rochacon]

Basecamp kind does this, but it has a single $99/month unlimited plan. I also wanted this, because not all users need the entire product anyway (i.e. bug reporters, guests).

[syed99]

That’s a good point. They do charge for the integrations though per user. Majority of our user base though syncs with github and slack. That is kind of where the compute costs go up specially with GitHub syncs but there are avenues we can explore with upcoming pricing where that’s an option to use the base tool. Thanks for bringing up their pricing plan as an example.

[rocmcd]

Because per user pricing is in line with the value you are receiving as a customer. If you are not receiving $XXX dollars per month in value, why use the service at all?

You are trading money for time and efficiency, after all.

[nonameiguess]

Ironically enough, self-hosted Jira used to do this, until they got rid of the server licenses and forced everyone onto their cloud, and now they charge per user.

[syed99]

Yup they did. Back at my former workplace they basically stopped updates and overlaid it with packages such as support, upgrade packs and more. At the end the price ended up equating to the same cost as the private cloud instance.