IIBE

Four items, too much friction

I started IIBE after a frustrating trip to IKEA in Rishon. I had four items to collect, but managing the list on my phone and finding each product took more effort than it should have. I ended up asking several employees for directions. A list of ten or twenty items would make that much harder.

The friction started before the trip. The Israeli catalogue is primarily in Hebrew; switching to another country's English catalogue loses Israeli prices, stock, and product selection. I wanted an accessible interface that kept the local market data.

A list that works inside the store

The useful unit was not just a product name. I needed its image, exact article number, variant, quantity, collection section, and warehouse address together, with a simple way to mark it collected.

That became the product's flow: browse the Israeli catalogue, build a list, and use it as a collection plan. The table adapts into readable rows on a phone, with a card view sharing the same list state. Language switching preserves the current screen, quantities, and collection progress.

Integrating a catalogue without a public API

Manual product entry would have undermined the app's purpose. Without a documented public API to integrate, I investigated the requests used by IKEA's Israeli storefront and built a C# integration with its search endpoint.

The backend handles searches and pagination, preserves exact variants and article numbers, and filters results to Israeli product pages before returning them to React. Article numbers stay identifiers, preserving leading zeroes.

An empty result is different from a timeout, a failed request, or an unexpected response format. The app distinguishes those states. The integration depends on the storefront's implementation and needs maintenance if that changes.

1. Israeli storefront
2. C# integration
3. React interface

A category is not a pickup address

A living-room category does not tell a shopper where to collect a sofa. Furniture may be displayed in the showroom but picked up from the self-service warehouse; smaller products belong to marketplace departments.

I imported the Israeli category tree and mapped roughly 900 categories to collection sectors. The mapping uses exact category identifiers and parent context, with reviewed rules for ambiguous cases rather than relying on similar product names.

Changing stores refreshes availability and pickup information while retaining the list and collection progress. The previous store's address disappears immediately while the new information loads.

Route through the stops that matter

The first route followed too much of the normal store circuit. I wanted a path through the required collection sectors that could use shortcuts and then reach the exit.

I represented the marketplace's paths and shortcuts as a weighted graph. Floyd–Warshall finds shortest paths between graph nodes; Held–Karp determines the shortest entrance-to-exit walk through the required stops. Numbered stops connect the resulting SVG route to the list.

The route recalculates when items are collected or restored. Products in the same sector share a stop. Items without mapped locations remain visible separately instead of receiving invented coordinates.

Outcome and limitations

IIBE is a working shopping companion combining live Israeli search, store-specific availability and pickup details, a persistent list, and a collection route.

The route is planning on a shared schematic, not precise indoor navigation. The schematic is based on an older Rishon layout and currently serves all supported stores. Store-specific aisle and bin information can be factual while the route remains approximate. Product descriptions from the Israeli catalogue may remain in Hebrew.

The central engineering task was making incomplete, differently structured sources useful together while keeping verified store data separate from the app's own suggestions.