Blayn Mobile Order

QR table ordering for Japanese restaurants, taken from a missed release to shipped.

2 months

from joining to phase-one release

Existing product and team effort, not a build from zero

people on the team

In short

A Japanese restaurant ordering product. Customers scan a QR code at the table to start a session, browse the menu and order, paying either before ordering or after eating. I joined after the project missed its release, introduced a new frontend architecture, and completed phase one within two months. I also maintained bManager, Blayn's existing sales-tracking app.

Who it is for

Restaurant customers ordering from their table by scanning a QR code, and shop owners tracking sales in bManager.

The problem

The project had already missed a release date when I joined. Beyond catching up, the ordering flow had to support two different payment moments, work from a plain QR scan as well as a LINE-connected journey, and hold its layout on the older mobile browsers customers actually bring to a restaurant.

What I delivered

Introduced a new frontend architecture to the existing codebase after joining the delayed project.
Implemented dynamic menus and checkout.
Built the arrival and deferred-payment QR flows, covering both payment before ordering and payment after eating.
Adapted the existing LINE integration so both the QR-only and the LINE-connected journeys work.
Worked on holding the intended layouts together on older mobile browsers.
On bManager: fixed a launch failure affecting newer ARM64 Android devices, including the Android API and Firebase upgrade work, and released the fix.
On bManager: addressed Firebase Cloud Messaging problems on newer devices, within the limits of the existing app.

Engineering challenges

Joining a project that already slipped
The release had been missed before I arrived. Rather than patching around the existing frontend, I introduced a new architecture and rebuilt the ordering flow on it, which is what made the phase-one date reachable.
Two ways to pay, one session
Paying before ordering and paying after eating are different flows off the same table session. I built the arrival and deferred-payment QR journeys so both resolve to the same order.
An app that would not launch on ARM64
bManager failed to launch on newer ARM64 Android devices. The fix ran through Android API and Firebase upgrade work on an app I did not originally build, and I released it.

Outcome

The team completed the work for the phase-one release within two months of my joining. The bManager launch failure was fixed and released.

Phase-one release completed within two months of joining a delayed project
Two payment moments: before ordering and after eating
ARM64 launch failure fixed and shipped on an existing app

References

Product pages and store listings for this work. They show the product, not a breakdown of who built which part.