MMH POS

Retail workflows, shaped with the shop

MMH POS is designed for small and medium-sized shops in Myanmar, such as grocery shops and small retail and wholesale businesses. I am developing it with a home-based shop as the first client. Much of this project involved understanding how the shop operates and turning those practices into clear business rules. I asked questions, drafted workflows and refined the approach through discussion and review.

I work across the Flutter application, NestJS APIs and data handling. The goal is to connect what happens at checkout with the stock, purchase and balance records someone needs afterwards.

Products, units and pricing

A shop may sell the same product as individual items, packs or cases, with a different price at larger quantities. MMH POS supports multiple product units, with price tiers based on the quantity sold.

I worked on product and checkout flows that keep units, price tiers and stock locations understandable.

Credit sales and returns

A sale does not always end with full payment. The credit-sale workflow records what remains unpaid and connects the customer’s balance with the sale. Returns add another step: relating a correction to the original transaction and accounting for the goods and money involved.

Building these flows meant thinking beyond a checkout total. The records need to explain what happened at the sale, what changed later and what is still owed.

Inventory and expiry

Inventory connects product information with stock by location, including shop-floor and storage quantities. Purchasing brings stock into that workflow, while stock views help explain what is available and where it is held.

For goods where dates matter, the project includes batch expiry details, near-expiry and expired-stock views, and configurable expiry settings.

Roles, permissions and approvals

In a shop with several people, not everyone should be able to do everything. MMH POS starts from four role templates: owner, manager, cashier and staff. The owner has full authority. A cashier focuses on checkout. Staff roles can be set up for tasks such as receiving purchases or counting stock.

Permissions, not role names alone, decide what each person can do. Sensitive actions such as price overrides, refunds and large stock adjustments need confirmation with an owner or manager PIN. The record keeps who made the change, who approved it and why.

Choosing a practical offline scope

Coordinating offline selling across several devices raised stock-accuracy concerns. I scoped offline selling to one device to keep stock coordination practical for the first client’s home-based shop.

The one-device scope applies to offline selling. PowerSync and SQLite support the local data layer.

How the parts fit together

• Flutter and Dart: the Android and Windows client.
• TypeScript and NestJS: backend operations and APIs.
• PostgreSQL: the primary backend database.
• PowerSync and SQLite: the client data layer and local storage.

Working across these layers makes data decisions part of interface design: a stored unit or balance must still make sense when someone reads it later.

Reviewing quality with ISO/IEC 25010

I use the product-quality characteristics from ISO/IEC 25010 as a lightweight checklist when reviewing my work: functional suitability, reliability, performance efficiency, usability, security, maintainability and compatibility. It gives me consistent questions to ask. Do totals stay exact? Can work recover after an interruption? Can someone with little technical background complete a sale? Can a cashier reach only what their role allows?

This is a reference for my own reviews. MMH POS has not been formally assessed or certified against the standard.

Original purchase, current balance

A receipt needs to explain both the original purchase and what is owed today. Later payments or changes to product units should not change the meaning of the original record.

I moved the original purchase summary above the items and separated original amounts from the current balance. Unit labels use the information recorded at purchase time.

What I learned

The most challenging part was turning everyday business practices into rules the software could follow. Working closely with the client made me more careful about asking detailed questions, revisiting assumptions and checking how a workflow would be understood in use.

Designing for SME shops in general while building with one home-based shop taught me to separate what this client needs now from what the product should support later. I am proud of working through a project that was more complex than I first expected, in both the interface and backend. It brought together the parts of development I enjoy: understanding a business, thinking through architecture and making complex workflows easier to use.