This is like writing a cost function for a global optimization algorithm for a problem with tons of parameters. You will very soon find out that the optimizer is much more adept at finding highly rated, but extremely useless outliers than you are at writing a competent cost function.

Herein lies the path to coming home to a cart filled with very-cheap-cause-it-expires-tomorrow produce and no tooth paste because it didn't make the cut under some top dollars limit you introduced to fix another optimization loophole.

I mean, this sounds like every other day at the store for me.

Which, if you break it down further:

1. Everyone's "algorithm" is different. Even if you could bake every possible filter into your eGrocery product, can you imagine the UX nightmare?

2. The "that I like the most" is a tough thing to quantify. Who is "I"? Me? My wife? My kids? My mom who's coming to visit this weekend? What do I like? Specific brands? Things I've bought before? From that store, or a different one? Things I might like because they share characteristics?

That's why user-scripting makes sense!

The downside, for the vendor, is that I'd also wind up scripting price-searching at multiple local grocery stores for equivalent items. If I can just curbside pick up what I need at both stores, they're literally next-door to each other.

The irony is that if those two stores were to cooperate and work together on a unified scripting system, both would gain sales on average; yeah, if an ear of corn is 50¢ at Safeway and 75¢ at Raley's, Raley's would lose that sale, but if Raley's happens to also sell mayonnaise for $1 v. Safeway's $1.50, and I can order both at the same time to fruitlessly attempt to satiate my insatiable hunger for elotes, then both would get a sale (and same deal if one or the other is cheaper on the chili powder and/or cotija).

We used to have such an API in the UK with Tesco, but that looks to have withered: https://www.tescolabs.com/category/api/