How Algoramming built ATAM Tailoring, a Flutter and Firebase app for a Doha tailoring shop that captures thobe measurements, runs the full order lifecycle, and prints customer, cashier, and tailor receipts to an 80mm thermal printer.
Al Tawash Al Maliky, a tailoring shop in Doha, ran on paper. Every custom order carried measurements, a fabric, a delivery date, and a balance between advance and total, spread across three slips for the customer, cashier, and workshop. Slips were easy to lose and gave the owner no view of revenue.
We built ATAM Tailoring, a single Flutter app on Firebase for mobile, web, and desktop. It captures each order with measurements split across five garment parts, recalls returning customers, runs a five-stage order lifecycle, and prints customer, cashier, and tailor slips to a network thermal printer.
One app now runs the counter and the owner's reporting. Every custom order is captured with its full measurement breakdown and prints the same three slips the shop relied on, straight to its existing thermal printer. Orders are searchable from booking to delivery, with live revenue in Qatari Riyal.
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.
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:
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.
| Capability | What it does |
|---|---|
| Custom order capture | Records customer identity, fabric, quantity, and measurements split across five garment parts (placket, sleeves, collar, pocket, buttons) |
| Three-slip printing | Prints customer, cashier, and tailor receipts to an 80mm thermal printer over the local network |
| Order lifecycle | Moves every order through pending, under processing, ready for delivery, delivered, and cancel |
| Repeat-customer recall | Autocompletes name, ID, phone, and past measurements from earlier orders |
| Owner dashboard | Status totals, a 30-day delivered-revenue figure, and a monthly or yearly revenue chart in Qatari Riyal |
| Role-based access | Admin, Manager, and General User levels gate every sensitive screen |
| Cross-platform | One codebase ships to Android, iOS, web, Windows, macOS, and Linux |
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 heart of the product is the order itself, and it is worth walking through how one moves through the app.
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).
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.
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.
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.
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.
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.
The interesting work sat in the seams, where a mobile app meets a shop's physical hardware and its bilingual paperwork.
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.
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.
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.
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.
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.
The design choices all trace back to how the shop actually operates.
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.
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.
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.
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.
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.
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.
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.
Want a system like this for your business? Get in touch with Algoramming.
I've been using this CRM software for the last 2 years and it has truly transformed how we handle our operations. This software is a game-changer in terms of efficiency and functionality. A top-notch software solution that has exceeded our expectations. Really appreciate themselves. The after-service of their product is just outstanding.
01 · RelatedHow we built the AI-native CMS behind algoramming.com, a Next.js 16 and Supabase platform that researches, writes, illustrates and publishes long-form SEO articles to four social networks every night, with a human in control by choice.
Read case studyWe will reply in plain English within one business day, NDA on request. Discovery call is free.
FeaturedAlgonize is the cloud ERP, CRM and POS platform built in Dhaka for multi-branch retail shops, restaurants and delivery businesses. This case study shows how one real-time dashboard unifies sales, inventory, riders, loyalty and accounting across Android, iOS, macOS and the web.
Read case study
