POSSystems

Kurdish means both Bahdini and Sorani

This is worth stating plainly, because it is the thing almost every vendor gets wrong.

Bahdini and Sorani are not interchangeable. A staff member in Duhok, Zakho, Amedi or Akre reads Bahdini. A staff member in Hawler or Sulaymaniyah reads Sorani. Handing either one the other dialect and calling it "Kurdish support" means your cashier is working in a language they have to slow down to read — on a screen they use several hundred times a day.

In the systems I build, Bahdini and Sorani are separate, complete languages, not one label with one translation behind it:

• Every interface string exists in both, written by someone who speaks Bahdini natively
• Receipts, invoices and printed documents render correctly in both
• The staff member picks their own dialect at login — a Duhok branch and a Hawler branch of the same business can each work in their own
• Product and customer names are stored so that both dialects, Arabic and English coexist in one record without corrupting each other
• Right-to-left layout is built in from the start, not patched on afterwards

Plus Arabic and English, for a total of four working languages in one system.

This is not a plan — it is running. smile.krd, my dental clinic platform, is live in production in exactly this configuration: English, Arabic, Bahdini and Sorani, with each clinic selecting its own dialect and every label in the system editable, right down to the receipt.

What I build

A POS is not one screen. It is a checkout flow, an inventory ledger, a payments layer, and a reporting layer that all have to agree with each other at the end of the day. I build all four.

### Checkout

• Barcode and keyboard-first entry — the till should be usable without a mouse
• Fast product search in Kurdish, Arabic and English
• Split tender: part cash, part wallet, part card, on one bill
• Held and parked sales, returns, and voids with a reason code
• Receipt printing to thermal printers, including a second accounting copy where the business needs one
• Shift open/close with a cash-drawer count and a variance report

### Dual currency, done properly This is the single thing imported systems get wrong, so it is worth spelling out. In the systems I build:

• Products can be priced in IQD or USD, per product
• A house exchange rate is set by the owner, with a change log
• The rate is snapshotted onto every transaction — so a report run three months later still reconciles, instead of silently re-pricing history
• A single bill can be tendered in mixed currency and change given in either
• Gateway settlement in IQD reconciles cleanly against a USD-denominated ledger

### Inventory that the checkout actually updates

• Stock decremented at the moment of sale, not by a nightly batch
• Multi-branch and multi-warehouse, with transfers between them
• Batch and expiry tracking — non-negotiable for pharmacies and food
• Low-stock and near-expiry alerts
• Purchase orders and supplier records
• Stock-take mode with variance reporting

### Payments Wired to the rails people here actually use — FIB, ZainCash, FastPay, AsiaPay/AsiaHawala and Qi Card — plus cash and card. See Payment & bank integrations for how each one works.

### Reporting

• Z-report and X-report per shift
• Sales by product, category, staff member, branch, hour of day
• Margin by product, once cost prices are loaded
• Books structured for a 15% corporate income tax filing and a 30 June deadline
• Export to Excel, because your accountant will ask for it

Built for these businesses

Restaurants and cafés — table map, table-side ordering on a phone or tablet, kitchen tickets, course firing, split bills, service charge, multilingual menus.

Supermarkets and grocery — high-speed scanning, weighed items, price checks, promotions, supplier and purchase-order flow.

Pharmacies — batch and expiry control, generic-name search across Kurdish, Arabic and English, supplier records, controlled-item flags.

Retail and fashion — variants (size, colour), barcode label printing, multi-branch stock visibility.

Salons, clinics and service businesses — appointment-linked checkout, staff commission, customer history. This is what SalonSystem already does in production.

Dental and medical clinics — treatments and retail products in one checkout, instalment plans, per-line-item insurance coverage, thermal receipt printing, and an end-of-day cash drawer audit that reconciles. This is running today in smile.krd, live in clinics across Duhok, Hawler and Sulaymaniyah.

Hotels and guesthouses — front-desk terminal, deposit capture, dual receipt printing, folio posting. This is what MotelSystem already does in production at tourism.krd.

AI inside the till, not bolted onto it

I also build AI automation and AI assistants — and when the same person builds your POS and your AI, the AI gets to see the data. That is the whole difference between AI that works and AI that demos well.

What that actually looks like in a POS:

• Reorder suggestions that learn your patterns — not a fixed minimum-stock number, but "you will run out of this on Thursday, and last Ramadan you sold four times as much"
• Supplier invoice extraction — photograph the delivery invoice, and the lines are read, matched against the purchase order, and posted. This is the single highest-return AI feature in retail and the one most businesses here still do by hand
• Natural-language reporting — the owner asks "which branch lost money last month and why" in Kurdish, on their phone, and gets an answer instead of an export
• Anomaly flags — a till with unusual void or discount patterns, stock shrinkage that does not match sales, a price that was changed at 11pm
• An AI assistant on WhatsApp for your customers — order status, opening hours, product availability, in their own language, wired to live stock rather than to a static FAQ

### Why Kurdish AI is the hard part General AI models handle English well, Arabic acceptably, and Kurdish badly — Bahdini worst of all, because there is far less written Bahdini for them to have learned from. Anyone who tells you they will "just add AI in Kurdish" has not tried it.

Making it work takes deliberate engineering: careful prompt and retrieval design, your own business vocabulary supplied as ground truth, evaluation against real messages from your actual customers rather than a demo script, and honest fallback to a human when confidence is low. I do this work because I need it for my own products, and because Bahdini is my own language.

What this is built on

Next.js and TypeScript on the front, PostgreSQL on the back, deployed to the edge so a checkout screen in Duhok is not waiting on a server in Frankfurt. Multi-tenant installations use row-level security, so one business can never see another's data. Your data is exportable in full, at any time, with no lock-in.

How pricing works

I don't publish a price list, because a POS for a single till and a POS for a six-branch supermarket group are not the same product, and any number I printed would be wrong for one of them.

What I do publish is exactly what moves the price, so you can estimate your own scope before you ever speak to me:

Pushes it down

• One branch, one till
• Standard checkout, inventory and reporting with no unusual workflow
• Single currency
• One payment method, or cash only
• Clean product data you can hand over in a spreadsheet

Pushes it up

• Each additional branch or till
• Kitchen operations — table map, table-side ordering, kitchen tickets, course firing
• Batch and expiry control (pharmacies, food)
• Full dual-currency with reconciliation
• Each additional payment wallet integrated
• Migration from an existing system, especially one with messy or partial data
• Hardware integration beyond standard thermal printers and scanners
• A workflow specific to your business that no product models

What you get before committing: a free scoping call, then a written proposal with a fixed scope and a fixed price. Not an hourly estimate that grows. If the scope changes mid-project, we agree the change and its cost in writing first.

Monthly running costs — hosting and services — are quoted separately and openly, and they are small relative to the build.

What I will tell you honestly

If you run a single till, sell fewer than a few dozen lines, and are happy with what you have — you do not need me. If an off-the-shelf product genuinely fits your business, I will say so and tell you which one. I have walked away from projects before and I will do it again.

Where custom is worth it: multi-branch, dual currency at real volume, an unusual workflow that no product models, or an integration nobody else will build for you.

Book a free 15-minute call →