2Go

Context & Challenges

2GO is entering a market with no direct analogs. The closest thing in Tashkent is Bizzon.uz, a Groupon-style coupon service, but the mechanic is different: users pay for the coupon upfront, there are no real-time promos, and there is no B2B tool for restaurants. Uzbekistan does not really have a happy-hours and live-promo aggregator yet. That is both the opportunity and the challenge. There is no established user pattern to lean on, and restaurants are not used to managing promos through a digital tool, so the B2B side had to feel extremely clear and intuitive.

User App

In Yandex Eats or Wolt, the user has a clear goal: order food. In 2GO, the user just wants to know where the best deal is right now. So on the Overview screen we help them find nearby places with promos, tune the feed with filters (venue categories, promo types, distance sorting, and search), and also push our own priorities by highlighting the best paid placements. We also give extra emphasis in the tab bar to the map, where users can instantly see nearby restaurants and active deals.

The subscription does not block browsing. People can scroll through anything they want, but the promo code only opens for authorized users. The barrier appears at the moment interest is already there, not before.

The restaurant card is built around the chain, not a single location. Inside, users see all promos across the chain, but they can still pick a specific branch or sort the list. It makes the UX a bit more complex, but it reflects reality: people think "I want to go to McDonald's," not "I want to go to McDonald's on 7th Proyezd Niezbek Yuli." When coming from the map, the branch filter is applied automatically, so the card opens with the selected branch already in place.

After the waiter redeems the code, the customer gets a modal asking them to rate the deal. If the user is not in the app at that moment, it appears on the next open. Without that, you lose most of the feedback.

B2B Dashboard

The B2B side has three access levels: chain owner, chain manager, and branch manager, each with different permissions. One account can also own multiple chains. To get started, the user has to create a restaurant, add branches to it, and only then create promos.

"Redeem promo code" is the most frequent flow for a branch manager. A waiter uses it at the cashier many times a day: the customer shows a 6-digit code, the waiter enters it, and the system returns either success or an error. I suggested generating a QR code on the user side and letting the waiter scan it, which is both convenient and standard, but the client turned it down because of technical limitations. Time at the cashier is tight, so the branch is prefilled and the code inputs are large enough to avoid misclicks.

Admin Panel

This is an internal tool for platform moderation. The admin reviews requests to create and edit restaurants. Instead of rejecting the whole request, they can fix the data right during review, since all inputs stay editable. In edit requests, we show only the fields that actually changed, which makes comparison much faster and easier.

The admin also manages the moderator team: invites by email, removes people with instant access revocation, and configures push notifications right from the panel, including title, text, send time, and frequency. Active and archived notifications are stored separately.

Outcome

Three products with one shared logic, launched from scratch in a market with no direct analogs. Right now everything is at the final frontend stage.

All three products work as one system: once the waiter redeems the code, it becomes used in the customer app; once the admin approves a restaurant, it appears in the catalog. That required syncing the logic across all interfaces already at the design stage, which is exactly the kind of end-to-end flow work I love.