I debugged listed company 91APP-iCHEF for free. Restaurants across Taiwan are getting their average tickets shaved.

A five-star review exposed a rookie mistake: the POS sync overwrites multi-select back to single-select. My hotpot shop isn't the only one hit. So is every store in Taiwan that depends on add-on logic.

I spent an afternoon debugging 91APP-iCHEF

Update, May 12:

I built a business-insight page out of this case: http://case.4force.com.tw

Interested? I'm still bleeding money. What's an AOV suppression case? This is one. Thank you.

May 10, 2026. One of my core Uber Eats customers, eighteen orders with us so far, left a five-star review:

“The meat slices are checkboxes, so you can't add two or more portions. Hope you can fix this.”

Five stars. She still gave us five stars. Then I went into the system.

The problem is simple. We're a hotpot delivery brand running iCHEF POS, integrated with Uber Eats and foodpanda. The core add-on logic of hotpot is that a customer can order the same meat more than once: pork ×2, beef ×1. In the restaurant business this is called Quantity in Modifiers. It is not some new feature.

Current state:

foodpanda: works
Uber Eats: one portion per item, max (single-select checkbox)

I spent an afternoon reproducing it myself:

Manually enable multi-select in the Uber Eats back office → the storefront works
Run a sync (publish) from the iCHEF back office → Uber Eats is forcibly overwritten back to single-select

I recorded every step, uncut.

This isn't a serious bug. It's a seriously stupid bug

Crashes and force-quits are engineering incidents. This is a product-comprehension incident.

Uber Eats supports this natively in its own back office, and the API is open. That leaves three possibilities:

BD never negotiated it: they can't handle a partner integration
R&D never wired it up: product priorities have been wrong for a long time
Support never cared: when a problem comes in, they treat the customer's head as the thing to fix and never look at the actual problem.

And foodpanda works, which means the logic layer already exists. The Uber side not being connected is not a technical problem.

The support SOP is the whole machine in miniature

Today I went around with iCHEF support for nearly two hours. She kept explaining that “if you set it to single-select, it syncs as single-select.” That's correct. It is not what I asked.

What I asked was: I set it to multi-select, so why does it turn into single-select after the sync?

Those two sentences are not the same sentence.

The support SOP trains her to “explain the spec,” not to “understand the customer's problem and escalate it.” Which tells you this company's service design exists to protect the company from being wrong, not to fix the merchant's problem.

In the end I wrote up a complete incident report myself and fed it to her. Only then did she pass it to engineering.

Then I read 91APP's investor relations page

“Built on AI-driven technology and insight capabilities, the company provides integrated omni-channel solutions that connect online and offline operations”

A quantity modifier for extra meat at a hotpot shop, and it took a customer's review to catch it.

When 91APP acquired iCHEF, the market expected an integrated upgrade. What we've seen so far: big-company priorities pointed the wrong way, wrapped in pretty IR copy.

iCHEF counts its customers in the tens of thousands. Any shop that needs “multiple portions of the same add-on” is affected: hotpot, yakiniku, bubble tea. Thousands of shops? I don't know. But I know somebody's AOV dropped. And I have my own numbers, plus the screenshot of that kind five-star review from a regular.

“This is 91APP's share price over the past two years.”

Here's the test video

https://www.youtube.com/watch?v=hqcIungClbg

If iCHEF's subscription billing broke for 72 hours, do you think they would “let it slide”? The whole company would be lit up all night until it was fixed.

But when the merchant's revenue feature breaks, they're happy to let support walk you in circles.

Free advice for the engineers:

After the system sends the payload to Uber, why is there no monitoring layer running a diff check between the values you sent and the values set in the iCHEF back office?

Is monitoring order patterns really that hard? The share of orders with multiple add-on quantities drops to 0%, and your alerting doesn't automatically blast the PM?

This isn't a technical problem. It's a question of whose money you think matters more.

First published on Vocus, 2026.05.10.