Hacker Newsnew | past | comments | ask | show | jobs | submit | danpalmer's commentslogin

I use WhatsApp for almost all my communication with family and friends. I'm also happy to pay for things that improve my experience.

...but it's unclear what this subscription would give me. The announcement has no real details, the article is light on detail, and the WhatsApp website has no mention of this subscription.

I get that it's hard. What I want is a good text and call app, and that's hard to charge for at scale. But every feature that Meta has added to justify charging (AI, stories, profiles, etc), makes the product worse for me and makes me less likely to pay for it.

They're in a hard place.


This is just fraud.

"Friendly fraud" is accidental or with the correct intentions – such as the customer not recognising the charge and charging back.


Genuinely not recognizing a charge is not fraud, as that to me requires intent (or at least gross negligence, e.g., something like "I'll just dispute everything I don't remember, and not make a particularly good effort to remember anything at all").

"Just fraud" is already taken for "criminal c uses unwitting cardholder a's card at unwitting merchant b", so what's your objection against "fiendly fraud"?


This is the point. You could file criminal charges. You could win in civil court.

Yes, and Stripe could do much better to prevent it. And doesn't.

What would you like them to do?

Even in the post you're wishy washy about what you want. They offer a product that does enhanced fraud detection but you don't like that. You correctly call out that there's major risks with taking a merchant's report and using it to flag a user's future transactions.


The article mentions Stripe's product in this space: https://stripe.com/en-us/radar

There are similar offerings from other companies. I don't know if bundling this with payment processing is common.


They could, but this isn't discussed in the blog post. The post is about literal fraud, which has a very different recourse for the merchant.

In the UK as a startup we found buying Silicon Valley SaaS tools to be a bit different sometimes in similar ways.

Europe, even the UK, prices tech startup significantly lower than the US (a colleague once said that in the US you get funding to turn an idea into execution, in Europe you get funding to turn your execution into money), plus we were tech/retail, so our valuation was just never the same as a pure-tech (or SaaS) business.

Because of this, we had numerous SaaS pricing discussions where the sales rep didn't seem to understand that their pricing was just a non-starter for us. "Why wouldn't you pay $15k a month to save half an engineer's worth of work?"... because our engineers don't cost that much, and we don't have that money.

So much of SaaS pricing is predicated on customers being B2B, pure-tech, VC-funded, plenty of funding, with exceptionally high engineering costs. Essentially: cost is not a concern. Most of the world is not going to pay another $30/m subscription for every employee.


I am at a pretty good (for european standards) startup, entirely bootstrapped with no investor money. We use virtually 0 SaaS ourselves with the exception of tailscale. The pay $40/user/month pricing seems insane for what most of these things do and they are almost always trivial to selfhost. Of course if you have millions of investor money to waste, it’s a drop in the bucket.

Same. And even for Tailscale we use a European alternative (Xplicittrust), because this aggressive growth of VC backed American tech is a real turn-off. We have seen where that leads often enough by now.

A bit turned off by their 'contact us for pricing' line.

Why not show your pricing like any other provider does?


They only sell indirectly. Common concept in Europe.

Funny, I've recently (and repeatedly) had the exact opposite experience while negotiating SaaS contracts for my largely London-based startup.

Contact UK sales team? They don't believe we could even use their product because we're not a BigCo with thousands of employees. After weeks of back and forth calls, they ask us to pay $100k to get "certified" for API access, with further details on pricing available afterwards. Endless warnings about multiple customers purchasing the API product but lacking the technical ability to implement it.

Contact US sales team? Contract signed and account set up within 2 days, $3k a month. Same company, same product.


> customers purchasing the API product but lacking the technical ability to implement it

Oh, wow, salesdrone. Sell me harder on what a good interface you’re selling.

What else, do we have occasional non-reproducible behaviour? Frequent stability and scaling issues? … … non-standard error codes, dare I hope?

Don’t tell me, the excitement is in finding out the hard way, just take our credit cards.


That particular API is actually perfectly fine, stable and relatively pleasant to work with. I have absolutely no idea what the UK sales team was trying to do. Some kind of negging? Perhaps they trained at Tate university.

Why does a company in GitHub's place allow employees to install random VSCode extensions?! That seems grossly irresponsible.

Because centralized management of resources is the death of innovation, intrinsic motivation and speed?

The dreaded "process" to get a single tool registered, working and allowed, is the reason a company is slow, dysfunctional and usually failing at a task.

The security tax and speeding tickets on everything are a luxury destroying much value.


This is the new old way. This was fine before irresponsible use of AI. Between vibe coding and using AI to find vulnerabilities as a result of vibes, I'm afraid that we will have to find ways to have more controlled environments.

It seems likely that some companies where the trade off shifts will head in that direction.

The problem with controlled environments is that even when done sensibly by people with good intentions they do slow things down and a lot of orgs will decide the trade off isn’t worth that.

I’ve worked for companies that did have much more controlled environments but given everything is made of a thousand packages these days and those packages have CVE’s and you do need to patch doing it after the fact is a recipe for paralysis.


Move fast, break things, get internal repository leaked and lose all the 9s.

Im pretty sure GitHub reliability issues are a result of Microsoft centralized management (i.e migrate everything to azure, the only allowed cloud)

Tbh, at this point why does it matter if it was MS or not?

I don’t think it does, I was just pointing out their issues are likely caused by the centralized resource managementent (mentioned by https://news.ycombinator.com/item?id=48219114 you responded to), and not the „move fast, break things“ aspect. Just my guess. But yeah, it doesn’t matter if it is MS or GitHub itself

Your company getting hacked because of random plugins for emerging or dysfunctional ecosystems that don’t have enterprise management solutions yet is worth it to avoid friction?

Yes and no.

The friction they should have probably had here is: did this employee need access to 3,800 internal repos?

I'm with the poster above in believing restricting what you can install makes a lot of things more difficult, but if you're going to take the risk you should be limiting the blast radius.


It's true. But at the same time, isn't it crazy to conclude that a company should restrict their developers from using their own developer productivity tools and services? If Microsoft devs shouldn't use random VSCode extensions, how could anyone?

You're assuming they allow it, but it might be against policy.

I’m pretty sure there is an policy on their internal wiki saying you shouldn’t do that.

Problem is: most employees don’t care to read these. Although I’m sure something like this could have been checked for during commit.


They can enforce it with an MDM. Policy should be enforced where possible not just notified to people.

Absolutely agree. But enforcing is so much more effort than creating wiki pages with LLMs.

Fair point, I hadn't considered this, but wouldn't they just disallow it?

Like, I use a VSCode fork at work, but the enforced extensions store backend is based on an allowlist and extensions need reviewing to be available there.


When I worked at Amazon, I had to run a special Amazon Linux. But I could just install whatever I wanted. I used emacs with whatever plugins I wanted.

Big tech can be suprisingly not locked down!


Ah, that must have been AL2023, right? IIRC, it's tightly integrated with internal deployment toolchains like Apollo and Brazil (Amazon's internal package management and build systems).

> In here it sounds like this is a client to a third party service.

It's not, Micro.blog is a service made and run by the author.


> Apple also wanted more explicit terms of service and privacy policy links, so I cluttered up our welcome screen with more buttons.

This sort of starts from the perspective that a privacy policy is not important, and I get why people might think that, but I think it's a harmful perspective.

Having an explicit policy about how you handle user data is far more useful than ignoring the problem and pretending that you are good for privacy because you don't collect data for ads. Almost every app collects data in some way and it's important to lay those out and be explicit about them.

This is an attitude I see from a lot of small developers, and I think it's something devs need to get better at.


Most users have no interest in reading the privacy policy, and those who do will have no trouble finding it in some 'About' menu.

it should be there before you start using the app though

Right, It should be included in the app store page. Apple should have a specific place for it and it should be required.

7 minutes from bug filing to account restoration. This shouldn't have happened in the first place, but that's an excellent response time from the support team.

FWIW, centralising on a single harness in Antigravity seems like a great idea.

> It's strange such a big corp can't even afford to have proper support team

Railway say they are in touch with that support team.


god help them

I had good experiences with their support, and bad experiences with AWS support. tldr: YMMV.

I bet there's an aspect of normalisation here too. Tesla Solar Roofs were all about looks, all about not looking like you had solar panels, but as the world warms up (pun intended) to solar, having visible panels is less of a concern, and may even be desirable.


Solar Roof made sense when panels were seen as something to disguise


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: