And then 2026 feels like the perfect time writing Haskell. The code is handwritten, but whenever I got stuck with the build system or was just not getting the types right, I could fall back to ask AI to unblock me. It was never that smooth before.
Finally the best side projects are the ones you actually use and this one will be used for all my future grocery shopping.
Also there already exists this reverse engineered project: https://github.com/ByteSizedMarius/rewerse-engineering/
I do have a suggestion for your app though: Have it compare your basket of goods across different markets in your region to show you the cheapest option. I'm pretty sure this possibility is actually one of the reasons they locked down the API.
I've used Data from REWE in the past and made a comparison between a couple of cities in Germany (I believe it was Frankfurt, cologne, Berlin, Munich and Hamburg). Hamburg was by far the most expensive, often as much as 10-20% more expensive.
I really like your suggestion. I will put it in an issue and look into that. https://github.com/yannick-cw/korb/issues/4
This is a great idea. I just think the use case is not that big since REWE is the worst in the price/quality ration and just going to another shop would save you more.
I'd settle for just being able to sort items by unit price... I'm sure this is a [regulation-]solved problem in Germany though
What do you mean? The official REWE app and website provide just that.
> I'm sure this is a [regulation-]solved problem in Germany though
Not sure what you mean by that.
Check out smhaggle app on Android
https://play.google.com/store/apps/details?id=com.smhaggle.a...
What I suspect though: They mainly show current discounts. The REWE API exposes those as a separate list for each market. There's around 3.5k markets and each can set their own discounts and has their own product catalogue with their own pricing.
So it would be 3.5k API calls to fetch all offers for all markets. Which is doable.
But fetching all products takes like 100 calls per market. It's quite a bit of data. And I think most supermarket don't publish their catalogue at all since they don't have delivery options.
This is the future of doing groceries. Let us login with our credentials and let us do the search/filling the cart with agents.
Totally fine to do the payment only on the web, so everyone can be sure they only order what was wished, and not 300 avocados.
I think a big issue here is the lack of standard - there is no established way of where an MCP server should be hosted so that agents are easily able to find it. Right now, the best solution I could think of would be to serve it at something like rewe.de/shop/mcp and you'd manually have to register it with your agent.
B2C: Is it really surprising that a busines has no interest in providing more price transparency to their customers?
Might I suggest you remove your tin-foil hat and consider that:
- 99% of REWE customers almost certainly have no clue what an API is
- 99% of the remaining 1% know what an API is, but their day-job involves messing with APIs, so they don't want to spend their weekend-time messing with the REWE API, they just want to do their shopping at REWE.
- The final 0.1% are those who come on HN and pretend its all some sort of big conspiracy to minimise transparency by $evil_corp. :)
Do you really want the price of your shopping to increase because REWE now needs to find money to pay for a helpdesk for the millions of B2C API users ?
Businesses and services differentiating between B2C and B2B is nothing new, that is why the two different terminologies exist !
What next, you don't want to fill up your car at the petrol station (B2C) but you want to be permitted to buy a barrel crude oil direct from the drill and refine it yourself (B2B) ?
Did you implement your own OAUTH2 flow in haskell for this?
I'm a huge fan of Haskell and I'm really exploring it as my primary language now that AI has gotten so huge, not just because it makes it easier but also because I can really lock down what I allow code to do (through pure functions, type checking etc) and so I feel a lot more confident in AI generated code
I wrote a skill some time ago to support me with "agentic groceries" on my own - it's the future of shopping I would say.
My workflow:
- I paste in urls or text for receipts I will cook this week - agent extracts the ingredients, calculates cups to ml and such, replaces meat with vegi ingredients, replaces some other things I prefer always (often also creates a nice markdown receipe at this steo I can put into Obsidian) - check my list of favs, check search cache (so not every time the api is called, I'm a good netizen :D ) - ask me which items I have at home (no need to add to the basket) - search rewe api for multiple candidates and let me choose. - after each recipe I enter /new to start with fresh context - also I have a list of things I buy every week
I still put everything manually in the basket in the end, but this is not the thing which is time intensive.
Until it breaks in a few weeks.
> The suggestion engine (korb suggestion threshold) is re-implemented in Lean 4 with five mathematically proven properties: suggestions have positive frequency, are sorted descending, come from ordered and available products, exclude basket items, and respect the count limit.
It can search for items, add them to the basket, picks a delivery slot and does the checkout.
With a little more scaffolding in markdown files, this now takes care of my weekly shopping.
It would have been a cool project!
The workflow in our house is basically to use Siri to add items to an iOS Reminders list as the week goes on. Then, the day of or day before we plan to shop we fill-in with commonly purchased items or one-off things and go shop.
It's been on my TODO list to have an agent "skill" take the Reminders list, ask for additional items, and populate the cart to schedule a pickup. We tend to prefer going in the store though to browse the produce because our local Kroger isn't great about that. Pickup is generally reserved for the weeks where we're feeling a bit short on time.
Pun presumably intended?
The basic idea is to write a prove in Lean4 and then test both the production implementation (Haskell) and the Lean implementation against random inputs. Compare if the results are the same.
If that is the case -> you can be pretty sure the unproven production version is as correct as the proven lean version.
https://www.dev-log.me/formal_verification_in_any_language_f...
Haskell is indeed an interesting choice. ;)
how stable this is in practice? Internal APIs tend to break without warning when they update the app.