Hunger Inc Hospitality: item, combo and add-on reporting

What did Restrologic do for Hunger Inc Hospitality?

Restrologic runs the POS suite for Hunger Inc Hospitality, a restaurant group with 6 outlets on the platform. The most visible work is its item reporting. We rebuilt the item, combo and add-on reports so that each order line is counted as what the catalogue says it is, and we proved the output where it had to stay the same.

Which restaurants are on the platform?

The platform’s own data and test fixtures name The Bombay Canteen, O Pedro and Veronica’s. Together with the other outlets, the group has 6 stores on the platform. We name only restaurants that appear in that data.

The challenge

Hunger Inc’s menus are built from combos, variants and extras. A combo can contain components. A dish can carry a chosen variant. A customer can add extra cheese to a combo. The client’s catalogue holds 350 add-on products, and it is the only client on the platform that uses that product type at all.

In raw order data these all look like parent and child lines. Our original combo reports inferred a combo from the shape of its children: any parent with more than one child was called a combo. That works until a plain item with two options appears.

A second problem sat underneath. The order line records the role a child was sold in, while the catalogue records what the product is. For this client the two do not always agree. In one week, 143 order lines carried a chosen variant yet were typed as plain products in the catalogue. Their variant name quietly never reached the report.

How did we approach it?

We treated the catalogue’s product type as the authority for combos, since it was complete and consistent in the data we checked, and we made the order-line role case-insensitive so POS and aggregator spellings agree. We then changed each report only where the evidence said it was wrong.

Three rules guided the work:

• Change what is wrong, freeze what is right. The internal item-detailed family used by Hunger Inc stayed on its June 2026 definition. A test pins each report’s SQL to a checksum, so an accidental edit fails the build.
• Prove, do not assume. When we added date bounds so exports read fewer partitions, we ran the old and new SQL against production for 25 to 31 August 2026 and compared both directions row by row.
• Keep clients apart. Internal reports are gated to the tenant entitled to them.

What did we build?

• A report catalogue that lists only the reports a tenant is entitled to, introduced in June 2026.
• Item, combo and add-on reports that key on the catalogue’s product type and the line’s role. Combo components stay out of the add-on report, and extras a client types onto a combo stay in. Hunger Inc’s add-on figures were expected to drop, because the old report had counted combo components. That was the fault being fixed.
• A corrected variant column. From 5 September 2026 the single-item report folds the variant on the line’s role, so the 143 weekly lines show their variant name.
• Faster exports. Date bounds on the partition column let the database skip chunks it does not need.

What came out of it?

Aggregator orders reach the same warehouse. In a 14-day window ending in September 2026, this client had 219 Swiggy and 1,364 Zomato orders alongside its POS orders, so the item and add-on reports cover every channel.

What is the stack?

The reports run in a Go reporting service over PostgreSQL with TimescaleDB, queried through GraphQL and delivered as CSV or Excel files. The admin screens are Angular front ends over the same API.

Timeline

Want the same clarity from your own order data? See restaurant data analytics and BI, ask Reckoner a question in plain English, or read about restaurant technology.