DEV Community: Ohad Farkash

I Asked AI to Build a Shopping Basket Under a Hard Budget — Here's What Broke

Ohad Farkash — Fri, 28 Aug 2026 15:06:02 +0000

I run OneFindMe, an AI product-search front end for a
large marketplace. The last thing I shipped was a feature that sounds trivial and
isn't: type a need and a hard budget — "useful things for a big dog, 80 total" —
and get back a real basket of real products that never goes a cent over.

The word doing the work is real. The model is not allowed to invent a single
product, price, rating or shipping figure. Everything with a number attached comes
from the marketplace API. The model only gets to do the one thing it's actually
good at: understand what a human meant. Drawing that line is where all the
interesting failures lived.

Here's what broke.

What the AI is actually allowed to do

When someone types "useful things for a big dog, 80," the model does not return
products. It returns a plan:

{
  "domain": ["dog", "pet", "כלב"],
  "roles": [
    { "he": "Chew toy",  "kw": "dog chew toy" },
    { "he": "Leash",     "kw": "large dog leash" },
    { "he": "Brush",     "kw": "pet hair brush" },
    { "he": "Bowl",      "kw": "dog food bowl" }
  ]
}

That's it. A set of complementary roles that together serve the need, each with
a search keyword. No prices, no products, no ratings — the model never sees a
catalogue. Every role keyword then goes to the real search endpoint, in parallel,
and comes back with real listings: price, image, rating, order count, affiliate
link. The AI understood the intent; the marketplace supplied the facts.

This split is the whole design. The moment you let a language model emit a price
or a product name, you've built a very confident fiction generator. Keep it on the
intent side of the wall and it's genuinely useful.

The data that simply does not exist: shipping

The feature has a switch: does the budget include shipping? Honoring it turned
out to be impossible in the obvious way, because the affiliate API does not
return a shipping cost. It returns an item price and a delivery time in days —
never a freight figure. There is no endpoint that gives you "this item ships to
that country for X."

I could have had the model estimate shipping. That's exactly the invention I'd
banned. So the honest version:

"Include shipping" → filter the search to free-shipping items only. Now shipping is a verified zero, not a guess, and the budget math stays true.
"Products only" → ignore shipping entirely and say so.

Currency was a smaller version of the same lesson: the marketplace converts prices
server-side when you pass a target currency, so there is no live FX call to
reconcile per item — you just work in one currency the whole way through.
Coupons exist in the payload but change without notice, so they're surfaced as a
caveat, never subtracted from the total. If a number can't be trusted, it doesn't
get to move the budget.

Choosing items without going over: yes, it's Knapsack

Once each role has a pool of real candidates, picking a combination that maximizes
value without exceeding the budget is the 0/1 Knapsack
problem wearing a shopping hat.

I didn't reach for a full dynamic-programming solution, for three reasons: the
item count is small (a handful of roles, ~20 candidates each), the whole thing
runs inside a request budget of a few seconds, and there's a constraint textbook
knapsack doesn't have — diversity. Two chew toys is not a good dog basket even
if the numbers are optimal.

So it's a greedy build with a fill pass:

// 1. base: cheapest viable item per role, so every role is covered
for (const role of rolesByCheapest) {
  const pick = role.candidates.find(c => spend + c.price <= budget);
  if (pick) { basket.push(pick); spend += pick.price; }
}

// 2. fill: add new-role items (variety first), then upgrade to pricier/better
//    picks, until only a few units of budget remain
while (budget - spend > SLACK && basket.length < MAX) {
  const add = bestAffordableNewRole(spend);      // prefer an unused role
  const up  = bestUpgradeThatUsesBudget(spend);  // else spend up on a better item
  if (!apply(add, up)) break;
}

The base pass guarantees coverage. The fill pass is what makes the basket actually
feel like the budget you asked for — which brings me to the bug that embarrassed
me most.

The basket that spent 36 of a 200 budget

Early on, a "cosmetics basket, 200" came back at 36. Technically valid — every
item real, under budget, nothing invented. Practically useless. A customer asking
for a 200 basket and getting 36 worth of stuff feels short-changed, not thrifty.

The cause was the value function. "Quality first" scored items by rating and
sales, which has no opinion about using the budget. It happily picked one cheap,
well-rated item per role and stopped. The fix was two-part: scale the number of
roles with the budget (a 200 cosmetics basket wants 6–9 item types, not 3), and
add the fill loop above, which explicitly targets a near-full budget. Cosmetics at
200 now lands at ~199. Never over — that constraint is absolute — but close enough
that the number you typed is the number you get.

The bug that made it look like a scam

The one that actually scared me: a nail-polish basket returned a women's coat
for 80. Nothing about a coat belongs in a nail order.

Root cause was a relevance shortcut. Each role carried a "must contain" keyword to
filter noise, and the role top coat had contributed coat. A listing titled
"Women Suede Coat" matched coat and sailed through. A generic word from one role
had opened the door to a completely different category.

The fix was to stop filtering per role and filter per basket. The planner now
returns a domain — a few need-specific stems, in every language the title might
be in — and every item, whatever its role, must contain one of them:

const domain = ["nail", "polish", "manicure", "ציפורנ"]; // for "nail polish"
const relevant = p =>
  domain.some(stem => (p.title + " " + p.titleLocal).toLowerCase().includes(stem));

A coat contains none of nail / polish / manicure, so it's gone — regardless of
which role's keyword it happened to match. Precision beat recall here on purpose:
in a basket, one off-topic item reads as "this thing is broken," and I'd rather
drop a borderline product than ship the coat.

Speed beat correctness. Again.

The first working version took 10–16 seconds cold: one planning call to the model,
then N marketplace searches. Users don't wait 15 seconds for a basket; they leave.

Two things fixed it. The searches were already cached, so the second time anyone
builds a similar basket the role searches are warm. And the plan — the roles for
a given need and budget band — is cacheable too, and priority-independent, so I
cache it and skip the model entirely on a repeat. A brand-new query is still
~10s (N cold marketplace round-trips are the floor), but a repeat is 0.4s. As
the cache warms across users, more baskets land in the fast path. Same lesson I
keep relearning: a correct answer that arrives too late is a wrong answer.

What happens when a price changes after you build the basket

It will. Prices and stock on a live marketplace move by the hour. The basket you
show is a snapshot, and pretending otherwise is the same sin as inventing a
shipping figure. So the total is computed server-side from the freshest search at
build time, the items carry the marketplace's own "prices may change" caveat, and
the buy links go straight to the live listing where the real, current price is
authoritative. The basket is a starting point that respects your budget, not a
locked quote — and it says so.

The pattern underneath all of it

Every one of these fixes is the same move: let the model interpret, never let it
assert. It's brilliant at turning "stuff for a big dog, 80" into search terms and
domain anchors. It's a liability the instant it emits a price. Keep the language
work and the truth work on opposite sides of a hard wall, and the failures stop
being "the AI hallucinated" and start being ordinary, fixable engineering — a
missing field, a too-greedy heuristic, a generic keyword that matched the wrong
thing.

The budget basket that came out of it is live on OneFindMe if you want to see the
shape of it. But the interesting part was never the demo. It was the wall.

Localizing a marketplace search for 12 markets: the assumptions that cost me

Ohad Farkash — Tue, 25 Aug 2026 10:19:24 +0000

I run OneFindMe, an AI product-search front end for
AliExpress in 12 languages. Translating the UI was the easy part. The hard part
was everything I assumed about what each market wants — and kept getting wrong
until I measured instead.

This is three of those assumptions, what the data actually said, and the code
that changed. If you're localizing anything commerce-shaped past the string
table, you'll recognize the pattern: the bug is never the translation, it's the
belief underneath it.

Assumption 1: "same homepage, translated, is localized"

The first version showed every market the same "today's deals" row — the same
eight products, just translated. A shopper in Saudi Arabia and a shopper in
Brazil saw identical items in different words.

That isn't localization, it's translation wearing a localization costume. The
Gulf shopper doesn't want the same products as the Brazilian one; they want
things that sell there — an abaya, an oud diffuser, an Arabic coffee pot.
Showing them a translated version of someone else's shortlist is worse than
showing nothing, because it signals the site doesn't actually know their market.

The fix was per-market seed lists, chosen by audience before geography. A
single dispatch, checked in this order:

function dealsTerms() {
  if (lang === "ar" || ARAB_COUNTRIES.has(country)) return DEALS_GULF;
  if (country === "IL") return DEALS_IL;
  if (EU_COUNTRIES.has(country)) return DEALS_EU;
  return DEALS_INTL;
}

Language is checked before country on purpose: an Arabic speaker who happens
to be browsing from Germany should still get the Gulf row, not the EU one. The
person's language is a stronger signal of what they're shopping for than the IP
they happen to be behind.

Lesson: a translated shortlist is not a localized shortlist. Localize the
selection, not just the labels — and let the audience signal win over the geo
signal when they disagree.

Assumption 2: I knew what a market considered acceptable

Here's the one I'm least proud of, and the most useful.

A women's-clothing search on the Arabic surface returned some items I looked at
and thought: I should filter these out for a conservative market. I started
writing a modesty filter — block anything that looked immodest on the Arabic
side. It felt responsible.

Then I did the thing I should have done first: I opened the actual AliExpress
Saudi storefront, as a Saudi user, and ran the same query. AliExpress itself
puts "sexy"-labelled and form-fitting clothing on the first page of a plain
dress search there. Immodest clothing is the market norm, not an edge case.

My filter would have made my engine stricter than the store the shopper was
walking into anyway — blocking a sports bra from someone who searched for
women's clothing, while the destination site shows it on page one. That's not
protecting anyone; it's just lost results.

So I threw the modesty filter away. What I kept was much narrower: a filter for
things that were a relevance failure in any market — a fetish costume
surfacing on a search for "dress" is wrong for a shopper in Riyadh and one in
Tel Aviv. That list is short and explicit, and deliberately excludes words with
innocent uses (a "nightclub dress" is an ordinary party dress; "Lolita" is a
real fully-covering fashion style; "sexy" is 42% of AliExpress's own first
page).

Lesson: don't encode your assumption about a market into a filter. Go
observe the market — the real benchmark for what to show is the store the user
is heading to. I almost shipped a paternalistic filter built on a guess; four
minutes of looking inverted the whole decision.

Assumption 3: more traffic in a language means demand in that language

I'd built full localized pages for three Gulf markets, confident all three had
Arabic shopping demand. Then I pulled the search-console data per country, and
two of the three had almost no Arabic queries at all — the "traffic" was
my own users mis-geolocated through carrier routing and VPNs, searching in other
languages entirely.

I'd spent weeks building for demand that a five-minute export would have shown
me wasn't there. Worse: content I'd written as filler in one language quietly
out-performed the pages I'd carefully localized, because that's where the real
demand was.

Lesson: "traffic from country X" and "demand in language X" are different
measurements, and you can't tell them apart without looking at the actual
queries. Export the per-market data before you build the per-market page, not
after.

The pattern under all three

Every one of these was the same shape: a reasonable-sounding assumption about a
market I wasn't in, encoded into code, that a small measurement would have
corrected before I wrote a line. Translating strings is a solved problem.
Localizing judgment — what to show, what to filter, what to build — is where
the real work is, and it's all measurement, not intuition.

Localize the selection, not just the strings. A translated shortlist isn't local.
Let the audience signal beat the geo signal when they conflict.
Observe the market before you filter it. The benchmark is the store the user is going to, not your idea of that market.
Per-market demand data before per-market pages. Traffic ≠ demand.

If you're building commerce in markets you don't personally live in, the
uncomfortable truth is that your instincts about those markets are a liability
until they're checked. Mine were wrong three times in a row. Curious whether
anyone's found a faster way to catch these than shipping and measuring — the
comments are open.

I build OneFindMe — AI product search for
AliExpress by text or image, in 12 languages. It's free; it runs on affiliate
commission at no extra cost to the buyer.

Building a 12-language AI product search on the edge: what actually broke

Ohad Farkash — Tue, 25 Aug 2026 10:10:26 +0000

I run OneFindMe, an AI product-search front end for
AliExpress. You describe what you want in plain language — in any of 12 languages
— or upload a photo, and it returns the product, similar items, and cheaper
alternatives. It runs entirely on a Cloudflare Worker with an LLM doing the
language work.

This isn't a launch post. It's the three problems that were genuinely hard, the
wrong first solutions I shipped, and what actually fixed them. If you're putting
an LLM in front of a marketplace search API, you'll hit all three.

The stack, briefly

Cloudflare Workers for the whole API — search, translation, image understanding, caching.
Claude Haiku for query translation and image identification. I tried Sonnet too, but for this task — short product names and image labels — Haiku was actually the better fit, and it's far cheaper when every search is an LLM call.
Workers KV as the cache layer.
A static multilingual front end on Cloudflare Pages.

The core loop is: take a natural-language query in any language → turn it into a
clean marketplace search term → hit the affiliate search API → rank and filter →
return. The interesting failures are all in the "turn it into a clean search
term" step.

Problem 1: the model translated too well

The first version asked the model to "translate this shopping query to English."
It did — beautifully, fluently, and uselessly.

A user searching for a שמלת ערב (evening dress) got back
an elegant formal gown suitable for evening occasions. Grammatically perfect.
It also returned almost nothing from the marketplace, because nobody titles a
product listing in fluent prose. Marketplace sellers write
Women Elegant Evening Party Dress Sexy Backless — keyword soup, not sentences.

The fix was to stop asking for translation and start asking for the 2-3 word
noun phrase a seller would put in a title. The prompt changed from "translate"
to "return the short product name an AliExpress seller would use." Fluency was
the enemy; the model's instinct to produce natural language was exactly wrong for
a keyword search index.

Lesson: when an LLM feeds a keyword system, you don't want its best language.
You want the language of the target index. Prompt for that explicitly.

Problem 2: the model invented category IDs, and they outranked reality

To narrow results, I let the model suggest an AliExpress category ID alongside
the keywords. Category-constrained search returns cleaner results — when the ID
is real.

The model would confidently return category IDs that did not exist. Not
often, but often enough. And a nonexistent category ID doesn't error — it returns
an empty or garbage result set, which then replaced the perfectly good
keyword-only results the same query would have produced. The hallucinated
constraint silently beat the honest fallback.

Two things fixed it. First, a hard allow-list: category IDs the model proposes
are checked against a map of known-good IDs and dropped if unrecognised. Second,
and more important, the keyword search always runs; the category is an
optional refinement layered on top, never a replacement. If the category path
returns nothing, the keyword results are still there.

Lesson: never let a model's optional enrichment silently override your
deterministic baseline. Layer it, gate it, and make the baseline win by default.

Problem 3: cold search was 6-8 seconds, and that was the whole business

An uncached search does real work: an LLM call to build the query, the
marketplace API round trip, ranking, filtering. Cold, that's 6-8 seconds. Users
don't wait 6-8 seconds. The single biggest driver of bounce wasn't relevance —
it was latency on the first search.

The cache helps enormously: every search result is cached in KV for up to 30
days, so a warm search returns in ~200 ms. But you can't cache a query nobody has
run yet, and the first person to search a term pays the full cost.

Two moves cut the perceived wait to near zero without making the search
actually faster:

Instant bestsellers. The moment a search starts, the UI shows a row of known-good bestseller results for the category while the real search runs behind it. The screen is never empty; the real results swap in when ready.
Self-warming on unknown terms. When a new keyword is translated for the first time, the translation is saved and the search is pre-cached, so the next person to search that term — and there's almost always a next person — gets the 200 ms warm path.

Neither makes the cold path faster. Both make it invisible. That distinction —
optimising perceived latency instead of actual latency — moved the metric that
mattered more than any relevance tuning did.

Lesson: on a search product, the empty-state-while-loading is a feature, not
a gap. Show something instantly and backfill.

The one I'd warn you about hardest

A subtle one, because it looks like success: don't trust the marketplace's own
"is this product available" signal in isolation. The affiliate API would report
live, purchasable products as gone. Filtering on it alone silently emptied result
pages that should have been full. Availability needs corroboration, not a single
boolean — the same lesson as the hallucinated category, in a different costume:
one unreliable signal shouldn't be allowed to zero out a good result set.

What I'd tell myself at the start

Prompt for the target system's language, not the user's. A keyword index wants keywords, not prose.
A model's optional output must never override your deterministic path. Gate it against known-good values; layer it; let the baseline win.
Optimise perceived latency first. Instant partial results beat a faster spinner every time.
One signal should never zero out a result set. Corroborate before you filter to empty.

The engine runs in 12 languages now, and every one of those bugs showed up
identically in each. If you're building anything that puts an LLM between a human
sentence and a structured search index, you'll meet all four. Happy to compare
notes in the comments — especially if you've found a better answer to the
cold-search problem than "show bestsellers and pray."

I build OneFindMe — AI product search for
AliExpress by text or image, in 12 languages. It's free; it runs on affiliate
commission at no extra cost to the buyer.

The multilingual bugs that never throw: hreflang, JSON-LD and a site in 12 languages

Ohad Farkash — Sat, 22 Aug 2026 12:47:29 +0000

I run a search engine that publishes in twelve languages from one static site on Cloudflare Pages. Last week I audited its machine-readable layer — the part crawlers and answer engines read rather than humans — and found four problems.

None of them threw an error. None appeared in logs. Every page rendered perfectly. That is the whole point of this post: the multilingual layer fails in a register where nothing tells you.

1. The homepage was serving the wrong language to everyone abroad

The site's primary market speaks Hebrew, so / is Hebrew and /en/, /ar/, /de/ and nine others sit alongside it.

A middleware rule redirected visitors from one specific region to their language. Everyone else — including every English speaker on earth — landed on Hebrew.

My first instinct was to fix it with a broader geo-redirect: detect English-speaking countries, send them to /en/. This would have been a bad idea, and it is worth saying why.

Googlebot crawls predominantly from US IPs. A geo-redirect on / that keys off country would take the crawler off the Hebrew homepage and onto the English one almost every time it visited. You do not want your primary-market homepage to become the page the crawler can never reach.

The correct tool is hreflang, and it is what search engines built for exactly this. Checking the page, the tags were already there and already right:

<link rel="alternate" hreflang="he" href="https://example.com/">
<link rel="alternate" hreflang="en" href="https://example.com/en/">
<link rel="alternate" hreflang="ar" href="https://example.com/ar/">
<!-- …ten more… -->
<link rel="alternate" hreflang="x-default" href="https://example.com/en/">

Two things make this work, and both are easy to get wrong:

The set must be reciprocal. Every page in the group lists every other page including itself. If /en/ does not point back at /, search engines are entitled to ignore the whole cluster.

x-default is not "the default language" — it is the fallback for users you have no better match for. Pointing it at the Hebrew homepage would have been the intuitive reading and the wrong one. It belongs on whichever version serves someone whose language you do not publish, which for most sites is English.

With that in place, an English searcher gets /en/ from the search engine directly, and the crawler still sees the Hebrew homepage as the Hebrew homepage. No redirect needed.

The residual gap is worth naming honestly: hreflang is a search-engine protocol. A crawler that simply fetches your bare domain and reads what comes back — which is what several AI crawlers do — still gets your primary language. There is no clean fix for that from inside hreflang. What I did instead was make sure the English URL is the one used everywhere off-site, in every directory listing and profile.

2. Structured data claimed eight languages; the site had twelve

The WebApplication node carried:

"inLanguage": ["he","en","ar","ru","es","pt","tr","fr"]

Four languages had been added since that array was written. Nobody updates a hand-maintained list in a JSON-LD blob, because nothing breaks when it goes stale. It just quietly asserts something untrue about your site, in the most machine-readable place on the page.

If a value in your structured data duplicates a fact that lives elsewhere in your codebase — supported languages, prices, feature lists — either generate it from the source of truth or add an assertion. A test that reads the language directory listing and compares it to the array is about ten lines.

3. `sameAs` is the entity-linking mechanism and mine was two years behind

Organization.sameAs is how you tell a search engine "these profiles are the same entity as this site." Mine listed two profiles. Two more had been created and verified since, and neither was in the list.

This is the same failure as the language array, with higher stakes: the whole value of building profiles elsewhere is that the site claims them. Unclaimed profiles are just pages that happen to mention you.

One judgement worth stating: I deliberately left out a directory listing that had been submitted but was still in a moderation queue, because its URL 404s until approval. A sameAs pointing at a 404 is worse than an absent one — you are asserting an identity link to a page that does not exist.

4. The bug that nearly made me report the fix as a failure

I updated sameAs across the site with a scripted replacement, then wrote a verification pass to count how many nodes had changed.

It reported 21. The replacement had touched 365.

My verifier iterated over the top level of each ld+json block:

const items = Array.isArray(parsed) ? parsed : [parsed];
for (const item of items) { /* check item.sameAs */ }

Most Organization nodes are not at the top level. They are nested inside publisher, or author, or mainEntity. A flat scan sees a small fraction of them.

function* walk(node) {
  if (Array.isArray(node)) { for (const v of node) yield* walk(v); }
  else if (node && typeof node === "object") {
    yield node;
    for (const v of Object.values(node)) yield* walk(v);
  }
}

I was one step away from telling my client the bulk edit had barely applied. When you verify a change to nested data, walk the tree. A verifier that is structurally simpler than the data it checks will lie to you, and it will lie in the confident direction — a number, not an error.

The check I now run before any bulk edit to structured data

Bulk-editing HTML with string replacement is exactly as dangerous as it sounds, and JSON-LD has a nasty property: a broken block does not break the page. The browser ignores it, the layout is fine, and the damage is invisible until someone runs a validator months later.

So the script does this, per file, before writing anything:

Apply the replacement to an in-memory copy.
Extract every <script type="application/ld+json"> block and JSON.parse each one.
If any block fails to parse, skip the file entirely and log it.
Only then write, keeping a backup.

Then a separate pass re-parses every block on the whole site — 1,753 of them — and reports the count of unparseable blocks. That number has to be zero.

None of this is clever. It is just the acknowledgement that in the machine-readable layer, "it still looks fine" is not evidence of anything.