A UX Designer Walks Into
a Mithai Shop

I was working from home when I decided to "fix" my dad's business. That word — fix — should have been the first warning sign. The business has been running for decades. It didn't need fixing. But I'm a UX designer, which means I am professionally trained to find problems worth solving. And so I looked at Vrindawan Sweets — two outlets, one shared kitchen, a few hundred loyal customers — and I saw inefficiency.

The plan, in my head, was clean. Buy a POS system. Set it up in a weekend. Train the manager in an afternoon. Become the next-generation son who modernized the family business with technology. I had seen enough "digital transformation" articles on LinkedIn to be dangerously confident.

I subscribed to Vyapar — a well-known retail POS — and handed it to Manoj ji, our store manager, on what I imagined would be a triumphant day.

It took him about twenty minutes.

Advance orders are bookings placed days or weeks before delivery — primarily for events. Weddings where the entire sweet selection is custom. School functions with dozens of identical snack boxes. Government celebrations with specific packaging specifications. Corporate gifting orders negotiated over phone.

These aren't items rung up at a counter. They are complex objects with moving parts:

No POS on the market could handle this level of customisability without feeling like rocket science. So Vrindawan ran the way it always had: orders in a diary, copied by hand onto paper the night before, passed to the kitchen at dawn.

I gave up trying to fit the business into someone else's software and went the other way: I sat at the shop. For weeks.

The output of that time was a requirements document built from two tools: user stories grouped by role, and an object-action table — every noun the staff used (order, box, item, outlet, customer, payment) mapped against every verb that touched them (create, edit, print, cancel, mark paid). For each intersection: who does this, when, and what happens next?

What I found confirmed what the diary already knew — the workflow was mostly correct. The sequencing of steps, the information required at each point, the hand-offs between counter and kitchen. The decades-old system had been refined by real use. My job was to make it digital without making it wrong.

The menu catalogue already lived in a Google Sheet — every item, price, and category, maintained by my father for years. Rather than start from scratch, I connected it to AppSheet, Google's no-code app builder, and had something usable in a day. One week of trial with real orders was enough to confirm the workflow made sense — and to learn what it couldn't handle.

AppSheet showed the concept was sound. It also showed exactly where the edges were: custom box compositions, per-customer pricing flexibility, and a phone UI that felt like filing a tax return. That week earned the decision to build properly. The next version was a PWA built to last.

The first day of the kitchen trial went fine. The staff on duty could read English well enough. Most of our item names are transliterations — Kachori, Patisa, Chena Apple — so I assumed literacy would hold.

On day two, a different kitchen worker squinted at the printed KOT and said:

The app is in daily use at both outlets. It handles the parts of the business that no existing POS would touch.