You're thinking of pricing zones—shoppers in Zone A pay a different price than those in Zone B. This makes sense, for example, if shipping costs are higher in Zone B.
The bill in question is about per-shopper pricing (e.g, you and I pay different prices in the same store). This is something Lyft and Uber do, but it's not really possible in retail.
> This is something Lyft and Uber do, but it's not really possible in retail.
It is possible for retail. For example, you can simply not display the price. You can display a price range. You can use EInk displays which auto-update based on who's approaching the item.
And of course it's infinitely possible in an online store.
One example of how this is being employed is McDonalds trying to push everyone to use the app. They'll give lower prices in app while raising prices on the menu giving a "not using app" tax. That enables them to have flexible per user prices within the app. A store could do the same thing.
How would that work? The barcode on the item doesn't get rewritten, the checkout counter can't distinguish who picked up which exact item. Even if they did assign unique barcodes to each item, what happens if you take the item off the shelf, and put it in someone else's cart? They'd be charged the wrong price for the item.
The store could make it mandatory to swipe your fidelity care before calculating your prices. They already do something similar with specialized promotions.
If we're including promotions or membership discounts, then coupons fit this definition of price discrimination. And those have existed since the 90s at least.
The problems show up when different people don't have access to the same coupons published by the store. Most coupons are fine.
They haven't had the ability to do the significantly bad kinds of targeting until recently. This is a new problem even if it's similar to old practices at the surface level.
I think McDonalds dynamic pricing is great. Every time I checkout the app there is some crazy deal. Sure its not always something I want but I'm not necessarily competing w/ the other items on the menu. If there's no deal on something I want, I check BK or similar chains.
Refreshing the content on an electronic shelf label (ESL) takes about 30 seconds, and multiple people can view a product simultaneously. Unless the store is giving everyone AR glasses, people will notice the price discrepancy.
This assumes you have sufficient data to actually recognize a shopper such as facial ID or some form of iBeacon for every single product for which you wish to implement price discrimination. Basic ESLs cost $3 to $12, depending on size and use very little energy. Adding a camera means more energy, so a bigger battery and more cost.
Using in-app discounts is the most likely way to implement this, which I am okay with. Shoppers are willingly trading their data privacy for a discount.
I think viewing it at as a discount is framing it wrong. It’s more a fee for not using the app, and if you use the app you’ll get charged the highest price McDonald’s has decided you will pay.
Should this be legal is a question you could argue both ways, but in my opinion society will be worse off with per customer pricing.
> Using in-app discounts is the most likely way to implement this, which I am okay with. Shoppers are willingly trading their data privacy for a discount.
I'm not OK with this. Simple reason, it leaves the wide masses with no other option than to sell their data to survive.
> Using in-app discounts is the most likely way to implement this, which I am okay with. Shoppers are willingly trading their data privacy for a discount.
Your mistake is assuming it's a discount, when it's not. For example, Safeway near me charges exorbitant prices for goods which are anywhere from 30-50% lower in the app. What they're doing is the same as your average dark pattern, you're only getting the real price using the app otherwise they charge a no-app fee. And even then you can't tell what the real price is supposed to be, because the app will tailor discounts to your shopping behavior.
Shoppers can and have noticed the price discrepancy [1] which is why this legislation is happening in the first place. If the price isn't the price then the whole basis of capitalism and consumer choice falls apart because there's no way to make a proper determination if Store A is cheaper than Store B.
> It’s unclear to me why transportation demand pricing is allowed but not delivery.
I don't think it should be allowed. It's predatory. It allows a company like Uber and Lyft to see things like "Oh, you are going to a hospital, then I'm going to apply a 10% surcharge because you are probably desperate".
It also works against the drivers. Uber/Lyft see things like "This person is logged on for 8 hours, they are desperate, so let's give them lower rates and worse routes."
Why shouldn’t a company be allowed to price the product differently? For an airline, booking a flight 6 months out, 6 days out, or 6 hours out are different situations.
For Uber/Lyft, booking a ride into the middle of nowhere carries a cost for the driver that isn’t present when booking a ride to the airport.
A flat fee per mile doesn’t make sense. A flat fee per seat doesn’t make sense. Grocery stores already price segment via coupons, sales, and loyalty programs - this is just an extension of that.
You're literally saying "an airline, booking a flight 6 months out, 6 days out, or 6 hours out" is not "charging two people for the same route differently", completely missing the point of alex43578's excellent question.
I'm not. alex43578 was shifting the goalposts from the point cogman10 was making; I acknowledged what he said, but it was besides the point. An airline charging differently depending on the time ahead of flight is sensible. An airline charging differently depending on the buyer's home address is discrimination.
You said "charging two people for the same route differently" is bad: airlines do that constantly and that's why there's dozens of fare changes, fare buckets, sales, codeshares, etc.
Regardless, the bigger point is that businesses already have a ton of levers to move for pricing: sales, loyalty programs, and regular price adjustments. None of those are considered discrimination. Why does the buyer's home address fall into this protected class; particularly for any service that involves transport, delivery, etc to that address? There's a clear relevancy of the address to the cost of a service based around that location.
I suppose you are misunderstanding me on purpose, but let me try again in very clear terms anyway: Offering the same service or product (a specific flight if you will, a chunk of butter of the same brand in the same store at the same time) to two independent customers at different prices based on prior knowledge about them unrelated to the specific good or service is fundamentally unjust.
What you are referring to is 'price discrimination'[1]. @alex43578 is correct in his examples. In the 'Uber/Lyft' example, his metric for service similarity in the case of a ride to the airport vs. the middle of nowhere can be seen in the distance driven. The problem is that arguments can always be made on why pricing one demographic vs another makes business sense.
In the case of Uber/Lyft, the company can say a ride to the middle of nowhere costs more than a hotspot destination because the odds of finding someone hailing another ride from there are low. This would mean the driver would have to spend more on gas picking up their next customer. Although this seems reasonable, it's probabilistic in nature. This may also not be the case, but the company must price this risk to keep their drivers happy. Well what of the case where the destination is a dangerous neighborhood where the driver feels like their life will be in danger? How do we price the risk then? And that says nothing about the possible mismatch of perception between the seller and the customer.
How about if a grocery store sells goods at a higher price to customers in lower income areas because they notice that it lowers the number of high income area customers to the point they make less profit? Is it right for that store to raise the price for identifiably lower income area customer to make up for the lost profit?
> Offering the same service or product (a specific flight if you will, a chunk of butter of the same brand in the same store at the same time) to two independent customers at different prices based on prior knowledge about them unrelated to the specific good or service is fundamentally unjust
Your statement includes things like loyalty programs and memberships. Presenting these credentials at checkout means customers are willingly giving the company "prior knowledge about them" (that they've shopped at the store before and how much they're willing to spend) unrelated to the *specific* food or service they're purchasing. Should these practices be allowed?
The point of this reply isn't to say what should or shouldn't be allowed, it's to show that I believe the issue is more nuanced than you can account for in your statement of what constitutes unjust business practices.
Why is it unjust? It’s absolutely the store or individual’s choice to charge what they want to who they want, assuming that they aren’t discriminating against a protected class.
In your example, why aren’t all prices then fixed between different stores to ensure justice? Whole Foods shouldn’t be allowed to charge more than Discount Food Bin for the same can of beans, and WF in Oakland shouldn’t charge less than WF in Marin.
> sales, loyalty programs, and regular price adjustments. None of those are considered discrimination. Why does the buyer's home address fall into
Because everything you listed applies to everyone equally! Assuming a normal loyalty program anyone can join.
> any service that involves transport, delivery, etc to that address
Shopping at a grocery store doesn't involve that. But sure most forms of charging for transport based on destination are fine. That's different from charging two people differently to go the same place at the same time. "Home address" is just an easy piece of personal info to mention.
(An exception to that most would be like the hospital example, charging more for that specific location inside the general area because the buyer seems desperate.)
Just for clarification: Does this affect intraday price changes, and how much if this is AI vs. 'standard database operations'?
I'm thinking of scenarios such as 'Oh, we're going to have a heatwave between 14:00 and 19:00, let's make popsicles 9 cent more expensive for everyone' or 'hm, that particular brand of soda sells extremely good today, let's hike the price'/'this noodle soup gets new stock later today, let's lower the price to clear out the shelf'
Because with electronic signage, that is very possible.
Canada's major grocery chain has migrated entirely to LCD price tagging that can receive OTA updates. There are now no paper price labels in the store.
The same chains have extensive camera coverage on the entrance / exits of the store.
So pricing can be an optimization function as fine grained as persons currently in the store.
Cameras on the aisles as well can enforce that individual tags update while nobody is within 15 feet, etc.
It's hard to even talk or think about without without sounding (and becoming!) conspiratorial. Add a little data from our trusted partners and they can jack specific prices according to urgency - eg, floral bouquets when you're en route to a dance recital.
It’s hard to talk about without sounding conspiratorial because it literally is an unfounded conspiracy. The impracticalities of this scheme are immediately obvious and no evidence of it ever actually being implemented in physical retail exists.
It’s strange to see so many commenters celebrating the death of a company and the loss of so many jobs.
I flew Spirit a few times. The first time sucked because it was an emergency and I had no other option. The last few flights were great. We got the large seats up front for $75 extra. That plus parking at SJC was still cheaper than flying Southwest out of OAK.
The staff were friendly, and the gate was conveniently across from a lounge, so we had a truly great experience for those couple flights to Dallas.
Enjoying Spirit Airlines a-la-cart benefits is like enjoying the extra features in an Android phone or using a car to get somewhere quickly instead of waiting around for public transit. If you aren't showing the worlds that you can afford to go without, you aren't upper class.
It's probably the association with Trump, at least to those outside the US. Anything even remotely connected to that arsehole is, almost by definition, to be reviled. If he wanted to save it, there's probably a really good reason not to, without reading any further into the topic.
> make a code change and then deploy the changes to gamma and verify they work by making a sample request and verifying output from cloudwatch logs etc
This has been a godsend over the past week while deploying a couple services. One is a bridge between Linear and our Coder.com installation so folks can assign the work to an agent. Claude Code can do most of the work while I sleep since it has access to kubectl, Linear MCP, and Coder MCP. I no longer have to manually build, deploy, test, repeat. It just does it all for me!
Nothing is “trivial” when you combine humans and computers. I worked at the MIT Computing Help Desk during my undergraduate years. We joked that we received callas from Nobel laureates who could find subatomic particles but couldn’t find the Windows Start button.
My company is currently trying to rollout shared MCPs and skills throughout the company. The engineers who have been using AI tools for the past 1-2 years have few, if any, issues. The designers, product managers, and others have numerous issues.
Having a single MCP gateway with very clear instructions for connecting to Claude Desktop and authenticating with Google eliminates numerous problems that would arise from installing and authenticating a CLI.
The MCP is also available on mobile devices. I can jot down ideas and interact with real data with Claude iOS and the remote MCP. Can’t do that with a CLI.
You're producing technical debt. At some point you will invest more time fixing the vibe slop than it would have cost you to do the work yourself in the first place. A lot of vibe-coding just feels like shifting responsibility and resources from "development" to "incident response".
1) Testing for myself 2) Vibe code testing 3) Team members do work from scratch and try to break 4) can read and reason it out even if I come out with it myself.
You joke and folks downvote, but this is my biggest issue with WebStorm. I'm seriously considering switching for the first time in 16 years. Zed is quite snappy. The Claude Code integration in VS Code is brilliant. I've used the CLI in the JetBrains terminal. I had no idea I could revisit past conversations until I used the VS Code extension!
Zed is snappy in the same way that notepad ++ is snappy: If you don't support 10% of language features you can avoid the hard work. Unfortunately this means that non trivial projects have false positive errors everywhere.
They are not just more expensive, they are also slower. Last time I compared them, AWS ARM64 instances could easily run jobs 30% faster, for the same CPU/memory count, than those that GitHub offers.
Yikes! They seem to be gunning for services like WarpBuild, which we've used for a couple years to keep our costs low. The $0.002 per minute on top of WarpBuild's costs is exactly GitHub's new pricing scheme.
I'm happy for competition, but this seems a bit foul since we users aren't getting anything tangible beyond the promise of improvements and investments that I don't need.
The lever that matters the most with the new $0.002/min tax is to reduce the number of minutes consumed.
Given that GitHub runners are still slow as ever, it actually is a point in our favor even compared to self-hosting on aws etc. However, it makes the value harder to communicate <shrug>.
But you do have to figure out which ones are salient to you and how they map to your specific app's lifecycle.
As a very small example: would you need to handle `charge.succeeded` and `payment_intent.succeeded`? How would you dedupe processing these events vs `customer.subscription.created`? Today, there's a lot of incidental knowledge about your payment processor's specific approach to webhook events that you need to know in order to integrate them.
Yeah, this isn’t great today. We have been exploring Webhook bundles/groups for common integration shapes that make a bit easier to make the right choices based on what you’re doing and hope to have something out here to help soon.
Having to figure out which of the 100s of Stripe event types we need to handle and which ones overlap was the most stressful part of adopting their system. Simplification here is welcomed.
Sure, but everything from the Stripe UI down to their API is feature creeped. I remember using it 10 years ago and I got it working in 10-20 minutes. Last month I see it up for my new project and it took almost a whole day
I'd bet the typical payments integration has more complex requirements now than those from 10 years ago. That's what usually happens as a space becomes more important and, therefore, more regulated. Usually new entrants will come in and try to provide a tidier interface for solving an increasingly complex problem. In payments, as others in the comments have pointed out, that process is hampered by the gatekeepers involved.
You'd have to commit to building an amazing developer experience and navigating bank partnerships and compliance (per country), risk, antifraud, etc.
That's why the payments devex feels so behind the DB, hosting, or auth devex today.
The bill in question is about per-shopper pricing (e.g, you and I pay different prices in the same store). This is something Lyft and Uber do, but it's not really possible in retail.
reply