Building a Cross-Platform Tailoring POS for a Qatar Shop: Measurements, Orders, and Thermal Receipts in One App

Short answer: Algoramming built ATAM Tailoring, a Flutter app for Al Tawash Al Maliky Tailoring in Souq Al-Ali, Doha. It runs on Android, iOS, web, and desktop from one codebase. The app records custom thobe measurements broken down by garment part, moves each order through a five-stage lifecycle, and prints three separate receipts (customer, cashier, and tailor) to an 80mm thermal printer over the shop's local network. Firebase handles authentication, live order data, and file storage, while a role system keeps the counter staff, managers, and owner in their own lanes.

The business problem

A busy tailoring shop does not run on invoices alone. Every order carries a set of body and garment measurements, a fabric choice, a promised delivery date, and a running balance between the advance paid and the total due. Traditionally this lives on paper slips: one for the customer, one for the cashier, and one that goes to the workshop with the cutter and stitcher. Paper is easy to lose, hard to search, and impossible to report on. When a repeat customer walks in, the staff has to dig through old books to find the last set of measurements.

The owner of Al Tawash Al Maliky Tailoring wanted to move the whole operation onto a single system that the front counter and the workshop could both trust. The requirements were practical:

• Capture a full custom garment order, including measurements for each part of the garment, not just a total price.
• Print the same three paper slips the shop already used, straight to the existing thermal printer.
• Track each order from the moment it is placed until it is delivered or cancelled.
• Recall a returning customer's details instantly instead of re-entering them.
• Give the owner a clear view of daily and yearly revenue and outstanding balances.
• Keep the counter staff, managers, and owner on separate permission levels.

The solution at a glance

We built ATAM Tailoring as a single Flutter application that the shop runs on the counter device and that the owner can also open on the web. It is not a generic invoice app. The data model, the forms, and the printed slips are all shaped around how a Middle Eastern tailoring shop actually books a thobe.

Architecture

The app is written in Flutter and uses Firebase as its backend. State is managed with Riverpod, navigation runs on Beamer with route guards, and a small Hive store keeps local preferences such as the first-launch flag and theme choice.

Firebase carries the live data. Authentication supports both email and password sign-in and phone-number sign-in with a one-time code. Cloud Firestore holds two collections, users and orders, and the order list is read as a live stream so the dashboard and the order screens update the moment anything changes. Storage keeps profile photos.

The startup sequence in lib/main.dart is deliberate and ordered: it sets clean web URLs, initializes Hive and opens its boxes, registers the local type adapters, initializes Firebase, and only then starts the app inside a Riverpod scope. Web builds carry their Firebase options in code, while mobile builds read the native configuration files.

Rather than hide Firebase behind a repository layer, the app keeps each feature self-contained. Every screen folder under lib/src/screens/ splits into view/ for the widgets, provider/ for its Riverpod state, functions/ for its logic, and components/ for the smaller pieces. Auth is broken down further into login, register, and forget-password modules. This keeps each feature readable on its own and easy to change without touching the rest.

The order, from counter to workshop

The heart of the product is the order itself, and it is worth walking through how one moves through the app.

1. Booking the order. On the Add Order screen, staff enter the customer's name, Qatari ID, and phone as autocomplete fields. If the customer has ordered before, selecting them fills in their details and their previous measurements. The bill number is generated automatically from the newest order, so numbering stays sequential. Staff then record the fabric, quantity, delivery date, total amount, advance paid, and payment method (Cash, Card, or Others).

2. Capturing measurements by part. This is where the app matches how a tailor actually works. Instead of one measurement box, the form breaks the garment into five parts, placket, sleeves, collar, pocket, and buttons, each with its own set of slots plus an "Others" note. Those values are stored on the order as separate lists, so the workshop sees exactly what the counter recorded.

3. Saving and confirming. The finished order is written to Firestore using the bill number as its document ID, with the status set to pending and a record of which staff member placed it. A success dialog then offers the three print actions.

4. Printing the three slips. The customer slip shows the shop header, the totals, and the balance due. The cashier slip repeats the billing detail with the full measurement grid. The tailor slip is the workshop's production sheet, carrying the same measurement breakdown so the cutter and stitcher have everything they need. Printing a work slip also moves the order into the under-processing stage, so the act of sending it to the workshop updates its status.

5. Tracking to delivery. From the Orders screen, staff can search across name, phone, ID, and bill number, filter by status, edit any field, and advance the order through the lifecycle to ready for delivery and then delivered, or cancel it. When an order is ready, a one-tap button opens a pre-written message to the customer.

6. Reporting back to the owner. The dashboard folds the live order stream into status totals, a rolling 30-day figure for delivered revenue, and a revenue chart that can switch between a monthly and a yearly view, all in Qatari Riyal.

Engineering challenges worth telling

The interesting work sat in the seams, where a mobile app meets a shop's physical hardware and its bilingual paperwork.

Printing Arabic on a thermal printer that does not speak Arabic

Entry-level ESC/POS thermal printers render Latin text from their built-in font but cannot print Arabic script. The shop's slips carry Arabic labels for the garment parts, so we could not rely on the printer's own characters. We solved it by pre-rendering the Arabic labels once as an image and sending that image to the printer as a raster block, alongside the live English and numeric data. The result is a slip that reads correctly in both scripts on hardware that has no Arabic font at all.

Talking to the printer over the network, by hand

The shop prints to a fixed thermal printer on its local network rather than a Bluetooth device. To drive it reliably we wrote our own network printer layer that opens a raw TCP socket to the printer's address and port and writes the ESC/POS byte stream straight to it, with a connection timeout and clear success and failure states. The printer's address and port are set as constants so the shop can be pointed at its own hardware. Because a raw socket is not available in a browser, printing is limited to the native builds, and the web build is used for management and reporting.

One order, three audiences

A single order has to speak to three different readers. The customer wants the price and the balance. The cashier wants the billing detail. The workshop wants the measurements and nothing about money. We modelled this as three distinct slip renderers driven off the same order record, each pulling a fresh copy of the order from Firestore before printing so the paper always matches the latest saved state.

Remembering the customer

Re-typing a returning customer's name, ID, phone, and measurements is slow and error-prone. The order form's fields autocomplete from the existing order history, and selecting a past customer back-fills their saved details. It turns a repeat booking into a few taps.

One authorization model across every screen

The shop has three kinds of user. The owner (Admin) sees the dashboard, reporting, and user administration. Managers can book and manage orders. General Users are kept out of the sensitive screens. Rather than trust the interface alone, each protected screen reads the current user's role from Firestore and decides what to show, falling back to a clear "not authorized" message everywhere a blocked action is attempted.

Built for the shop's real workflow

The design choices all trace back to how the shop actually operates.

• The data model follows the garment, not a generic invoice. Splitting measurements across placket, sleeves, collar, pocket, and buttons means the workshop reads the order the same way it cuts the cloth.
• The lifecycle mirrors the counter. Pending, under processing, ready for delivery, delivered, and cancel are the exact states a tailoring order passes through, and the dashboard totals are grouped the same way.
• The balance is always visible. Because a tailoring order is usually part-paid on booking, every slip and the dashboard track the advance, the total, and the remaining due.
• The owner gets a real picture. A 30-day delivered-revenue figure and a switchable monthly or yearly chart give the owner a quick read on how the shop is doing without a spreadsheet.

Results

• A single Flutter app now runs the shop's counter and the owner's reporting from one codebase across mobile, web, and desktop.
• Every custom order is captured with its full measurement breakdown and prints the same three paper slips the shop already relied on, straight to its existing thermal printer.
• Orders are tracked from booking to delivery, searchable across customer and bill details, and never lost to a mislaid paper book.
• Returning customers are recalled instantly, and the owner has a live view of revenue and outstanding balances in Qatari Riyal.

Tech stack

Framework: Flutter and Dart, one codebase for Android, iOS, web, Windows, macOS, and Linux. Backend: Firebase, with Authentication (email and phone one-time code), Cloud Firestore (users and orders collections, read as live streams), and Storage for profile images. State and navigation: Riverpod for state, Beamer for routing with authentication and profile-completion guards. Local storage: Hive for lightweight preferences such as the first-launch flag and theme. Hardware: a custom ESC/POS thermal printing layer over a raw TCP socket to an 80mm network printer. Reporting and UI: Syncfusion Charts for the revenue chart, plus typeahead autocomplete, image picking and cropping, and a global loading and toast layer.

---

Frequently asked questions

What does the ATAM Tailoring app do?

It runs the day-to-day operations of a tailoring shop. Staff book custom garment orders with full measurements, print customer, cashier, and workshop slips to a thermal printer, track each order from booking to delivery, and give the owner a live view of revenue and outstanding balances.

How does the app store measurements for a custom garment?

Each order breaks the garment into five parts (placket, sleeves, collar, pocket, and buttons) and stores a small set of values for each, plus a free-text note and an overall measurement field. The workshop reads the order the same way the counter recorded it.

How does the printing work?

The app connects to an 80mm ESC/POS thermal printer over the shop's local network using a raw TCP socket, and prints three separate slips from one order. Arabic labels are printed as a pre-rendered image because entry-level thermal printers cannot render Arabic script on their own. Printing is available on the mobile and desktop builds.

Does it work on more than one device type?

Yes. It is a single Flutter codebase that builds for Android, iOS, web, Windows, macOS, and Linux. The counter uses a native build for printing, and the owner can open the web build for management and reporting.

How are staff permissions handled?

There are three roles: Admin, Manager, and General User. Each protected screen checks the signed-in user's role and only allows the actions that role is permitted, with a clear message when an action is blocked.

What backend does it use?

Firebase. Authentication supports email and phone sign-in, Cloud Firestore holds the users and orders as live data, and Storage keeps profile photos. Local device preferences are kept in Hive.

Key takeaways

• Model the product, not a template. Shaping the order around real garment parts made the app match the workshop instead of fighting it.
• Meet the hardware where it is. Driving the existing network thermal printer directly, and printing Arabic as an image, let the shop keep its paper workflow without buying new equipment.
• One order can serve three readers. Splitting the customer, cashier, and tailor slips off a single record kept every audience served from one source of truth.
• A single Flutter codebase can cover the whole shop. The same app runs the counter and the owner's reporting across mobile, web, and desktop.

---

Want a system like this for your business? Get in touch with Algoramming.