[mattkrick]

I built an open-source B2B SaaS that recently raised its Series A. While I'm not a solo founder, we were a team of 3 up until we raised our seed.

The difference I see is traduora looks like a project, not a company. Sell support! Don't give it away for free. If someone asks me for a bugfix, I show them the ticket in our open backlog & tell them if they want it done faster, they have to pay. Seeing their concern turned in to a ticket shows them that I care, but telling them I prioritize paid fixes tells them it's not a charity. Don't let them feel entitled.

[jandrese]

If they opt to not pay do you leave the bug in your system forever?

I've always been a little annoyed at this model, because with so many companies it comes down to "I paid you $120,000/year for this support contract and you're telling me you've been able to track down this bug I reported, but you're not going to fix it because it's not on the project your developers are currently working on." And then they get really miffed if you drop the support contract next year, telling us how we'll be locked out of security and feature updates, even though there were zero releases in the past calendar year. If I'm playing for the equivalent of a full time junior developer I expect at least some action on my bug reports.

[gcheong]

If they opt not to pay then the bug gets fixed according to severity and priority in the regular development cycles. It's possible it will never get fixed. I see your point with paid support contracts that don't give you anything, and you would be justified to cut your losses, but I think this was more specific to individual bugs that a company wants to up the priority for.

[bartread]

> I paid you $120,000/year for this support contract...

> If I'm playing [sic] for the equivalent of a full time junior developer ...

Equating $120,000/year with a junior developer salary is exactly the kind of tone deaf I see too much of on here[0], but in this instance it plays in favour of your argument.

Depending on exactly where you are in the world - even within the US - $120k might be a much more senior salary, or several developers worth of salaries. It then becomes perhaps even more galling that you're seeing zero service for that outlay.

[0] Yes: I know junior devs in SV might get this but SV is not the world.

[stirlo]

By the time you add overheads to the cost of that developer it is much closer to a junior than a senior in most of the developed world.

[doopy1]

If by "most of the world" you mean "some of the united states" then I would agree with you. HN gives folks a rose colored view of the tech job market.

[dilyevsky]

I don’t see how this argument is relevant to the discussion. Also not hn fault europeans decided to pay US and China for all their software.

[nix23]

Boom headshot ;)

[jandrese]

In the US overhead can effectively double the salary. It includes taxes, retirement, healthcare (huge), dental, HR overhead, etc... It adds up.

$60k base salary is definitely junior developer territory.

[bartread]

Again, this isn't really true although of course there are significant overheads beyond salary. Here are some somewhat UK-centric examples: pension, employer NI, other benefits such as healthcare, office space, equipment, heating and lighting (by which I mean all business utility bills), licenses and subscriptions. Still, the total cost of a junior, even taking all of these into account, is nowhere near $120k anywhere I've worked.

[thayne]

They way I wish it worked, although I haven't seen it really successfully implemtented is that instead of paying for a support contract, you could pay for support in a more a la carte manner. Such as say, pledging money to a bug or feature, and the dev team prioritizes based on how much money is pledged for different features and bugs, perhaps with some expiration so customers don't end up paying for a bug that isn't fixed until years later when it no longer matters.

[doopy1]

I think those economics don't stack up against a monthly subscription on an annual contract, unfortunately.

[thayne]

The two don't necessarily have to be mutually exclusive. Support subscriptions might still make more sense for enterprises. But an a la carte system allows individuals and small companies to influence prioritization and "vote with their wallets" without having to be able to afford a pricy enterprise support contract.

Support subscriptions could even include an annual/monthly/whatever number of credits to vote for issues, possibly at a discount compared to a la carte.

[KajMagnus]

I think you're right. And that it'd take rather much time & inconvenience, for the customers, to in effect "micro manage" payments for individual features, and agree internally about if to spend money on this feature or that feature

At the same time, maybe for some rare & "really big" features, it could be worth the extra administrative work, to pay for that particular feature

[KajMagnus]

Sounds like crowdfunding of new features / bugs, repeatedly, in the same software project — instead of crowdfunding a new project just once?

I wonder if there's any SaaS that specializes in this. Like, Kickstarter but for new features, preferably on the company's own sub domain? So as not to distract people with unrelated projects, when they visit the "features crowdfunding" page. And the audience would come from the company's website (but not from the "Kickstarter for features" company's website).

Or I wonder if Gumroad would think this sounded interesting.

> with some expiration so customers don't end up paying for a bug that isn't fixed until years later

Good point