Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SaaS We Happily Pay For

francescodilorenzo.com

Post reply on HN
Print view View original

201–210 of 229 posts

Re: SaaS We Happily Pay For

#201

Post by kevsim »

leetrout wrote: post #5

Linear looks fascinating. We’re using Zenhub now and it’s slow and misused in our org (one giant project board instead of separate boards per repo / project). Curious if anyone here is / has used linear and could compare their experience with it to Monday, Asana or Zenhub?

Just to toss another hat in the ring - people who are interested in a tool that has a lot of same performance/hotkey characteristics as Linear but takes a different approach to what a product management tool/issue tracker should be should take a look at Kitemaker (YC W21) [0]. We've also got great integrations to Github, Slack, Figma, etc. We've got a pretty generous free tier so you can try it out for quite a while with your team before you need to pay.

0: https://kitemaker.co

Re: SaaS We Happily Pay For

#202

Post by joshmanders »

yakshaving_jgt wrote: post #186
kyawzazaw wrote: post #145

Earlier quoted context omitted.

This comment sounds like the Infamous Dropbox Comment: https://news.ycombinator.com/item?id=9224 Time, energy, attention, creative limit is important for a tiny startups like this.

I don't think it is equivalent, because the Infamous Dropbox Comment is about the behaviour of non-technical consumers. There's a pretty vast chasm between a non-technical consumer trying to set up rsync and a software developer adding a Trello GitHub integration. It does seem frivolous to me to pay money to automatically close tasks when a linked pull request is merged. And paying $720 annually to host some frontend…

It's very equivalent. Developers have a hard on for saying "I don't need to pay $5/mo for this when I can just build it in a weekend myself" Then they half ass something that took them probably a month of fiddling to make happen, then they're so vested in this idea that their homegrown bastardization is superior that they spend more time justifying the insane loopholes and workarounds to make it somewhat usable...

Re: SaaS We Happily Pay For

#203

Post by yakshaving_jgt »

joshmanders wrote: post #202
yakshaving_jgt wrote: post #186

Earlier quoted context omitted.

I don't think it is equivalent, because the Infamous Dropbox Comment is about the behaviour of non-technical consumers. There's a pretty vast chasm between a non-technical consumer trying to set up rsync and a software developer adding a Trello GitHub integration. It does seem frivolous to me to pay money to automatically close tasks when a linked pull request is merged. And paying $720 annually to host some frontend…

It's very equivalent. Developers have a hard on for saying "I don't need to pay $5/mo for this when I can just build it in a weekend myself" Then they half ass something that took them probably a month of fiddling to make happen, then they're so vested in this idea that their homegrown bastardization is superior that they spend more time justifying the insane loopholes and workarounds to make it somewhat usable...

That's a total straw man argument.

It doesn't take "a month of fiddling" to add an integration like this. It's already readily available[0] and has been for half a decade. It's also $24 per month — not $5 — at their current scale. These aren't amounts to be sniffed at either. The $720 a year they're paying for "frontend hosting" is not far off what I pay my accountant.

[0]: https://blog.trello.com/github-and-trello-integrate-your-com...

Re: SaaS We Happily Pay For

#204

Post by renewiltord »

frankdilo wrote: post #169
renewiltord wrote: post #150

Earlier quoted context omitted.

$100/mo won't make or break this startup. Inability to move fast might. Money of this scale is not a problem. Remember the insight from The Goal . Optimize at the bottleneck alone.

This sounds interesting! Where can I read more?

The Goal - Eli Goldratt. The Phoenix Project - Gene Kim.

Re: SaaS We Happily Pay For

#205

Post by lwigo »

specialist wrote: post #196
cabalos wrote: post #110

Earlier quoted context omitted.

I think this is credit card company policy and not specifically Stripe. IIRC, there is some language regarding using your own credit card because it could potentially be used to give yourself a loan. Credit cards have a much higher APR and lower limits for a cash advance. Processing your own cards could be used as an avoidance.

> could potentially be used to give yourself a loan Noob question: Would using a debit card test the payment system without the self loan float?

I believe so, but it requires more infrastructure setup. You'll have to have a prod level test ACH account through Dwolla or something, then watch Stripe interact with that. It's not just as simple as switching card numbers, unless you just want to use your debit card or the company provided one.

Re: SaaS We Happily Pay For

#209

Post by mooreds »

localcdn wrote: post #188
drwicked wrote: post #178

Earlier quoted context omitted.

Yep, saves a lot of annoyance having to keep track of a bunch of logins across SaaSs especially when you need to revoke access when someone leaves, so instead of having to go to all the various services individually to deactivate the accounts, you can just deactivate their Google account or revoke its access to those services.

Ahh, that is a nice and unexpected bonus. Does “Sign in with Google” allow provisioning of new accounts with appropriate permissions for a service/SaaS by an admin? (I’ve only used OneLogin/Okta)

I'm not sure what level of permissions is available with "sign in with google". In my experience, that is handleded within the SaaS. Here's what's happened (at least in the companies I've worked in, which tend to be a bit smaller).

1. New employee hired 2. They get a gsuite account. This gives them access to google drive, gmail, gcal, etc. (This is the provisioning I think you are referring to.) 3. They can now login to asana, zapier, with their gsuite account, using "login with google" 4. Their permissions within these saas tools are managed by the admins in those tools (not from gsuite). 5. When an employee departs, you disable their gsuite account. Then they can't log in to any of the SaaS tools, since their google account is disabled.

If you want a user to have centralized RBAC or ABAC, you need to use a real IdP, not gsuite in the way I outline above.

If you are using SAML for gsuite, you can use SCIM, I believe, to provision, but that's a different flow than I have outlined above. https://support.google.com/a/topic/6400789 has more on that.

Re: SaaS We Happily Pay For

#210

Post by kyawzazaw »

oliv__ wrote: post #141
furyofantares wrote: post #137

I really appreciate this list. It's cool to see how people work, and I'm sure the folks building the services you're using appreciate the kind words. I also had kind of a strange reaction to it, which I tried to figure out, and I'll explain it in case it's at all representative of other reactions being posted here. I think it's just kind of intimidating to read a list of SaaS someone else uses. After reading the whol…

The more I read your comment, the less I understood it.

Same
Post reply on HN