DEV Community: Ahsan Mehmood

We Let AI Build SketchUp Models With Nothing But an API

Ahsan Mehmood — Thu, 20 Aug 2026 13:44:08 +0000

OpenSKP's writer API has no Chair class. No Table builder, no furniture module, nothing that knows what a chair is. It exposes materials, layers, groups, component definitions, and faces — the same primitives SketchUp itself is built from — and nothing above that. Which raised an obvious question once the writer shipped: could an AI coding agent, given only that low-level API and a plain-English description of an object, produce a real, correctly-structured .skp file?

We ran the experiment with two different AI coding agents, independently, with no shared prompt engineering between the runs. Both were pointed at the same generic API and asked to build furniture. Neither was given examples of chair geometry or table dimensions to crib from.

Chair, table, and an armchair

Output from an AI agent's own generated Python script, loaded straight into the OpenSKP web viewer with no manual cleanup.

The first run produced a scene with a dining chair, a side table, and an armchair — nine component definitions, thirty-eight geometry primitives in total, organized across three layers with four distinct materials. That structure wasn't hand-specified; the agent decided the layer and material breakdown itself, deriving it from how it reasoned about the objects (seat vs. legs vs. backrest as separate faces sharing a wood material, for instance).

Here's a representative excerpt of what the agent actually wrote, generating a chair leg as an extruded rectangular profile:

def add_leg(group, x, y, z, width, height, material):
    """Add a single tapered leg as a box primitive."""
    pts = [
        (x, y, z),
        (x + width, y, z),
        (x + width, y + width, z),
        (x, y + width, z),
    ]
    top = [(px, py, z + height) for px, py, _ in pts]
    face_bottom = group.add_face(pts, material=material)
    face_top = group.add_face(top, material=material)
    for i in range(4):
        side = [pts[i], pts[(i + 1) % 4], top[(i + 1) % 4], top[i]]
        group.add_face(side, material=material)
    return face_bottom, face_top

Nothing in that function is chair-specific — it's a general box-extrusion routine, the kind of primitive-geometry reasoning you'd expect from someone who understands 3D coordinate systems, not someone who was handed a chair template. The agent built its own mental model of "chair" out of boxes and faces, the same way a human modeler would work from scratch in SketchUp's own polygon tools.

An executive desk

A more complex single object: a desk with a drawer unit, modeled as nested component groups.

The second test pushed further into nested structure: a desk with an attached drawer unit, modeled as a component group nested inside the desk's top-level group — mirroring how a careful human SketchUp modeler would organize the same object, with the drawer as its own reusable component rather than geometry welded directly into the desktop.

A phone, viewed from both sides

Front and back views of the same AI-generated phone model — face winding and normals came out correct on the first attempt.

The third object, from the second independent agent run, was a simplified phone: a thin rounded body, a screen face, and a camera module. What's notable here isn't the object's complexity — it's the simplest of the three — but that face winding order came out correct without being told about it explicitly. Get winding backward and a face renders as invisible or inside-out from the "wrong" side; the model shown above renders correctly from both front and back, which means the agent's geometry reasoning implicitly respected consistent counter-clockwise winding, not just "some points that happen to form a face."

What this does and doesn't prove

This isn't a claim that AI agents can replace a SketchUp modeler for genuinely complex or organic geometry — everything shown here is bounded, rectilinear furniture-and-electronics geometry, well within what an LLM can reason about symbolically in coordinates and box-extrusions. What it does show is that OpenSKP's writer API is low-level enough, and clean enough, that an agent with no domain-specific tooling can drive it correctly: valid component hierarchies, sane material and layer organization, and geometry SketchUp itself opens without complaint.

That's the actual target for the API design — not "convenient for humans typing by hand," but "reasonable for a coding agent to drive from a plain description," since increasingly, that's who's calling it.

Try it yourself: github.com/iamahsanmehmood/openskp — MIT licensed, available for Python, TypeScript, .NET, Dart, and C++.

OpenSKP 1.1.0: A Native .skp Writer, Now in All Five Languages

Ahsan Mehmood — Thu, 20 Aug 2026 13:35:52 +0000

Until 1.1.0, OpenSKP was a read path. You could parse a .skp file — either container format, all five languages — and get materials, layers, geometry, and metadata out of it. What you couldn't do was make a new one. 1.1.0 closes that gap: a real writer, producing files SketchUp itself opens without complaint, shipped in Python, TypeScript, .NET, Dart, and C++ at the same time.

Why write support is a different problem than read support

Parsing forgives sloppiness in a way writing doesn't. A parser that mishandles an obscure edge case just gets slightly wrong data for that one field — annoying, but survivable, and often invisible unless you're specifically checking. A writer that gets the container format wrong produces a file that SketchUp refuses to open at all, or worse, opens with silently corrupted geometry. There's no partial credit.

That asymmetry shaped how the writer got built. It targets the modern VFF container exclusively — the ZIP-based, TLV-tree format used by SketchUp 2021 and later — rather than also targeting the legacy MFC stream format, because VFF is what every current SketchUp install expects by default and where new files should live going forward. Every writer feature was validated the same way the parser's correctness was validated originally: produce a file, open it with the real SketchUp SDK, and confirm the SDK's own reading of geometry, materials, and layer assignments matches what was intended, field by field — not just "the file has a size greater than zero and doesn't crash on open."

What the writer actually does

The API surface is intentionally generic rather than shaped around specific object types. There's no Chair class or Table builder baked into the library — you compose scenes out of the same primitives SketchUp itself works with:

Materials — solid colors, opacity, and image textures
Layers (tags) — for organizing geometry the way SketchUp's own Tags panel does
Groups and component definitions — the same grouping/instancing model SketchUp uses natively, including nested groups
Curves and faces — arbitrary polygon geometry with material and layer assignment per face
create() for a brand-new file, and open_existing() for loading a file, editing it, and writing it back out

open_existing() in particular was the harder of the two entry points to get right. It isn't a byte-patcher that finds the one chunk you touched and surgically rewrites it in place — that approach is fragile against any structural change (add a face, and every downstream offset in the container shifts). Instead it does a full parse of the existing file into the same in-memory model the writer already knows how to serialize, applies your edits to that model, and replays the entire thing back out through the same write path a brand-new file goes through. Slower than a patch, but correct by construction: if create() is trustworthy, open_existing() inherits that trust instead of needing its own separate proof.

Five ports, five different sets of bugs

The writer shipped in Python first, since Python was already the most mature of the five ports and the fastest place to validate the design against the real SDK. Porting it to the other four languages wasn't a mechanical translation exercise — each port's own CI caught real, language-specific problems that the Python reference implementation simply couldn't have surfaced:

C++ — a check_writable helper failed to compile under the CI's stricter build flags, a class of error Python's dynamic typing has no equivalent to catching until runtime, if at all. The C++ port also turned up a clang-format issue where the CI's diff report was silently truncating on longer violations, which needed fixing in the tooling itself before it could be trusted to gate anything.
Dart — trigonometric rounding in transform-matrix math didn't match the other languages' output bit-for-bit, traced to a difference in how Dart's math library rounds versus Python's, and fixed by aligning the rounding step explicitly rather than relying on each language's default behavior.
Two of the ports hit test-ordering bugs — tests that passed individually but failed when run as part of the full suite, because they shared mutable fixture state that Python's test runner happened to isolate in a way the other runner didn't by default.

None of these were writer-logic bugs in the sense of "the geometry is wrong." They were the ordinary friction of porting real, non-trivial code across five different type systems, build toolchains, and test runners — exactly the kind of thing that's invisible if you only ever ship one language, and exactly why keeping five active ports is more expensive than it sounds, but catches more than a single-language project ever would.

Shipping five packages at once

1.1.0 went out to all five registries in the same release cycle — PyPI, npm, NuGet, pub.dev, and a tagged GitHub Release with prebuilt C++ artifacts (C++ has no package registry equivalent, so it ships as a downloadable tarball/zip pair instead). Coordinating that many release pipelines in one pass surfaced two more process-level snags worth naming honestly: a batched multi-language tag push needed the tags separated out per-language rather than pushed as one lump, and pub.dev's own publish flow has a gotcha around tag naming that isn't obvious until it rejects a push.

Neither was a code bug. Both are the kind of thing you only learn by actually running a five-language release end to end, which is exactly what 1.1.0 forced.

What's next

Read and write both exist now, but write support is currently VFF-only — no legacy-MFC writing, and no re-encoding a legacy file into the modern container. Conversion the other direction (glTF, IFC, OBJ into .skp) is on the roadmap but not started. If either of those is something you'd use, the issue tracker is open.

Install:

pip install openskp          # Python
npm install openskp          # TypeScript / JavaScript
dotnet add package OpenSKP   # .NET
dart pub add openskp         # Dart

OpenSKP is open source under the MIT license: github.com/iamahsanmehmood/openskp

Why We Built OpenSKP

Ahsan Mehmood — Thu, 20 Aug 2026 13:22:37 +0000

Why We Built OpenSKP

If you want to read a .dxf file, there's an open specification. If you want to read a .gltf file, there's a Khronos Group standard with a public GitHub repo and a validator you can run against your output. If you want to read a .skp file — SketchUp's own native format — there is nothing. No spec, no schema, no reference decoder. Just a proprietary SDK, licensed by Trimble, that only runs where Trimble lets it run.

That gap is the entire reason OpenSKP exists.

The problem with "just use the SDK"

SketchUp's official SDK is a real, functional way to read and write .skp files — if your project can tolerate everything that comes with it: a native dependency tied to specific platforms, a license that constrains how and where you can ship, and no path at all if you're building for Linux servers, WebAssembly, or anywhere the SDK simply isn't available.

That constraint is exactly what two of the projects OpenSKP now powers ran into. FrameSmart, a 3D collaboration platform, needed to parse SketchUp files as part of a Linux-hosted pipeline. IngeTrazo, a Linux-first 3D modeler for civil engineering, was running the real SketchUp SDK through Wine — a working setup, but a fragile one, dragging a Windows-only dependency into a project that had no other reason to need it.

Neither of those is an unusual situation. Anyone building a pipeline tool, a headless converter, a web-based viewer, or a CI step that touches SketchUp files runs into the same wall: the only "real" way in is a native SDK that assumes you're building a desktop plugin on Windows or macOS.

Reverse-engineering, not guessing

Without a spec, the only way to understand the format is to look at real bytes and figure out what they mean — and then prove the theory rather than just believing it looks plausible. That distinction matters more than it sounds. A parser that produces geometry that looks right in a debug print is not the same as a parser that's actually correct; SketchUp files are dense binary structures where a single misread flag byte can silently corrupt geometry without ever throwing an error.

The methodology that held up: build real files with the actual SketchUp application (or, once OpenSKP's own writer existed, the real SDK as a validation oracle), then diff OpenSKP's understanding of those files against what SketchUp itself reports through its own API — material colors, transparency values, transform matrices, vertex positions, all checked field by field rather than assumed. Several real bugs were only caught this way: a legacy-format alpha byte that four of the five language ports were silently discarding, a face's texture-positioning data that was being parsed but never linked back to the face it belonged to, a slot-numbering edge case that corrupted any file crossing a specific size threshold. None of those would have shown up in a "does it produce a mesh" smoke test. All of them showed up the moment real SketchUp was used as the source of truth.

Two container formats, not one

Part of what makes this format genuinely hard is that it isn't one format — it's two. SketchUp changed its internal container completely in the 2021 release. Files from SketchUp 2021 onward use VFF, a ZIP-based container wrapping a TLV (Tag-Length-Value) binary tree. Files from SketchUp 2013–2020 use something structurally unrelated: a classic MFC CArchive object-graph stream, with its own class-reference and back-reference numbering scheme, no ZIP involved at all.

A tool that only reads one of these covers a shrinking slice of the real files people actually have sitting on disk — architecture firms, civil engineering practices, and product designers routinely have SketchUp libraries stretching back a decade. OpenSKP reads both, transparently, behind the same parse() call in every language, which is a meaningfully larger reverse-engineering effort than picking the newer, better-documented-by-inference format and calling it done.

Why five languages, and why not bindings

OpenSKP isn't a core parser in one language with thin wrapper bindings for the rest. Python, TypeScript, .NET, Dart, and C++ are five independent implementations of the same reverse-engineered format, each idiomatic to its own ecosystem — because a Python native extension is a poor fit for a browser-based TypeScript viewer, and a JavaScript parser is a poor fit for a native C++ desktop tool.

The tradeoff is real: five implementations mean five places a bug can hide, and cross-language parity has to be actively maintained rather than assumed. In practice that means every non-trivial fix gets checked against all five ports' actual source before being called complete, and the same real .skp fixtures get run through every language to confirm they produce identical geometry, layers, and materials — not just "each one compiles and returns something."

Where it stands now

What started as a read-only reverse-engineering project has grown into a full toolkit: parsing both container formats, converting to seven other formats natively (glTF, OBJ, STL, PLY, DXF, IFC4, JSON), and — as of the 1.1.0 release — writing genuinely new .skp files from scratch, in all five languages, with no SketchUp SDK involved at any point.

None of it required Trimble's permission, a license fee, or a Windows machine. That was always the point.

OpenSKP is open source under the MIT license: github.com/iamahsanmehmood/openskp

How We Reverse-Engineered the SketchUp (.skp) Binary Format to Build a Pure JS/Python 3D Viewer

Ahsan Mehmood — Wed, 24 Jun 2026 08:27:26 +0000

For years, if you wanted to build a web-based 3D configurator, a mobile app, or a server-side pipeline that processed SketchUp (.skp) files, you had one choice: integrate Trimble’s official, closed-source C++ SDK.

This meant managing heavy native binaries, dealing with cross-platform compiling issues, and complying with proprietary licenses.

We wanted to change that. Today, we are open-sourcing OpenSKP — the world's first pure, multi-language binary parser and WebGL viewer for modern SketchUp (v2021+) files. It runs natively in Python, TypeScript, Dart, and .NET with zero native dependencies.

Here is how we reverse-engineered the format and built the rendering engine.

📁 Dissecting the SketchUp VFF Container

Starting in SketchUp 2021, the file structure changed from a legacy OLE compound document to a Versioned File Format (VFF).

Under the hood, a modern .skp file is actually a ZIP archive disguised with a custom header.

If you read the first few bytes of a .skp file, you will find:

A 4-byte VFF magic number (FF FE FF 0E).
A UTF-16 encoded version string indicating the SketchUp build (e.g., {24.0.594}).
A local ZIP file marker (PK\x03\x04).

By finding the byte offset of the PK marker, we can seek directly to it and extract the ZIP contents natively in memory using standard libraries (zipfile in Python or fflate in JavaScript).

Inside the zip, we find:

model.dat: The core binary buffer containing all 3D geometry and instance nodes.
materials/: Folder containing XML files defining colors and opacity for each material.
meta/model_thumbnail.png: A pre-rendered PNG preview of the model.

🌳 Parsing the TLV (Tag-Length-Value) Tree

The model.dat file is encoded using a binary TLV (Tag-Length-Value) schema. Every node in the tree starts with:

Tag (2 bytes): Indicates the entity type (in hex).
Length (4 bytes): Indicates the size of the payload.
Value (variable bytes): The payload itself or child TLV nodes.

To parse it, we recursively traverse the buffer starting at offset 0. Here are the key tags we reverse-engineered:

F601: Root model container
7C15: Component definition (defining reusable 3D geometries)
6419: Component instance (placing a definition in 3D space)
C409: 3D Vertex (coordinate payloads)
B80B: Edge (linking two vertices)
AC0D: Face (linking edge loops and defining normals)
D007 & D207: Component metadata and Layer/Tag assignments

Here is the core recursive TLV parser implemented in Python:

def parse_tlv_recursive(data, start, end, container_tags):
    pos = start
    elements = []
    while pos < end - 6:
        tag_bytes = data[pos:pos+2]
        size = struct.unpack_from('<I', data, pos+2)[0]
        if pos + 6 + size > end:
            break
        tag_hex = tag_bytes.hex().upper()
        children = []
        if tag_hex in container_tags and size > 0:
            children = parse_tlv_recursive(data, pos+6, pos+6+size, container_tags)
        elements.append({
            'tag': tag_hex,
            'size': size,
            'children': children,
            'payload': data[pos+6 : pos+6+size] if not children else b''
        })
        pos += 6 + size
    return elements

📐 3D Planar Triangulation

SketchUp faces can be complex N-gon polygons containing outer borders and inner holes (like a wall with window cutouts). To render them in WebGL or export to GLB, we must triangulate these loops.

Since the vertices are defined in 3D space, we:

Retrieve the face's outward-facing normal vector from the AD0D tag.
Project the 3D vertices onto a local 2D plane perpendicular to the normal.
Perform a 2D polygon triangulation (handling holes) using libraries like Earcut (JS) or Shapely (Python).
Map the resulting 2D triangle indices back to the original 3D vertex IDs.

🚀 Getting Started

OpenSKP supports multiple environments natively. Here is how you can use it today:

Python 🐍 (Server-Side Pipelines)

pip install openskp

from openskp import SkpFile
from openskp.export import glb

# Open and parse the model
skp = SkpFile.open("villa.skp")
model = skp.parse()

print(f"SketchUp Version: {model.version}")
print(f"Total Layers: {len(model.layers)}")

# Export directly to web-ready GLB
glb.export(skp, "output.glb")

TypeScript / Browser 🌐 (Client-Side Rendering)

npm install openskp

import { parseSkp } from 'openskp';

// Parse array buffer locally in the browser
const reader = new FileReader();
reader.onload = (e) => {
  const model = parseSkp(e.target.result);
  console.log("Parsed Layers:", model.layers);

  // Render model._glbPrimitives directly into a Three.js scene!
};
reader.readAsArrayBuffer(file);

🏠 Production Battle-Tested

OpenSKP is already running in production to power real-time 3D configurations for framing systems at Frame-Smart!

Special thanks to Noor Ali Qureshi (@nooraliqureshi) for contributing crucial parsing fixes that enabled seamless support across multiple legacy and modern SketchUp file versions.

⭐️ Contributions welcome!

OpenSKP is licensed under the MIT License. If you want to contribute, check out the source code, open issues, or submit PRs on GitHub:

👉 https://github.com/iamahsanmehmood/openskp

I Built the First Deterministic Urdu Compound Word Detector — Here's Why It Took a Full Library to Get There

Ahsan Mehmood — Mon, 27 Apr 2026 18:32:27 +0000

Urdu is spoken by over 230 million people. It is the national language of Pakistan, one of the 22 scheduled languages of India, and the lingua franca of a diaspora spanning three continents. And yet, if you try to build Urdu software today — real software, not a toy — you will hit the same wall every other developer hit before you: the tools do not exist.

I hit that wall building HamaariUrdu, an Urdu language learning platform. This post is about what I built to fix it.

The bugs that no library could fix

I was not looking to build a library. I was looking to ship features. But the bugs kept piling up, and none of the available Urdu NLP libraries (UrduHack, URDUNLP, or anything else) could fix them.

Bug 1: Search returning zero results for words that are obviously in the database.

The database stored ہے using the correct Urdu ہ (U+06C1, Heh Goal). The user's keyboard typed Arabic ه (U+0647, Heh). Both look completely identical on screen in Naskh fonts. But U+06C1 !== U+0647. Zero results. No error. No warning. Just silence.

Bug 2: String equality silently failing.

"قلم" === "قلم"  // false — why?!

One of those strings was copied from Microsoft Word and contains an invisible ZWNJ (Zero Width Non-Joiner, U+200C) that Word inserts automatically. You cannot see it. Your editor does not show it. But the comparison fails.

Bug 3: TinyMCE destroying Izafat.

In Urdu grammar, Izafat (اضافت) is a grammatical construction that links two words — like the English "of" but expressed as a marker on the first word. The marker is often an apostrophe-like character (U+2019, Right Single Quotation Mark).

TinyMCE — a very popular rich text editor — silently converts U+2019 to ’ before saving. So a word like کتابِ (with Kasra) or a phrase using Izafat apostrophe gets stored as an HTML entity. Every compound word lookup in the database then fails because the stored form doesn't match the queried form.

Bug 4: Numbers overflowing.

Urdu text frequently references South Asian scale: لاکھ (100,000), کروڑ (10,000,000), ارب (1,000,000,000). These are real everyday numbers in Pakistan — newspaper headlines, financial documents, government statistics.

Number.MAX_SAFE_INTEGER is 9,007,199,254,740,991. A single کھرب (1 trillion) value loses precision with typeof number. JavaScript silently gives you the wrong answer.

Bug 5: Sorting broken for every Urdu word list.

No database and no JavaScript runtime has native Urdu collation. The Urdu alphabet has 39 letters in a specific order that does not match either Unicode codepoint order or any Latin-derived collation. Every sorted word list was wrong.

Bug 6 — the worst one: Compound words destroying every downstream NLP task.

This one deserves its own section.

The compound word problem

Urdu مرکب الفاظ (compound words) are multi-word expressions that function as a single semantic unit but are written with spaces between their parts.

کتاب خانہ  →  library  (کتاب = book, خانہ = place)
بے عزت     →  disrespectful  (بے = without, عزت = honor)
خوش قسمت  →  fortunate  (خوش = well, قسمت = fate)
علم و عمل  →  knowledge and practice  (fixed expression)
محنت مشقت →  hard work  (synonym compound)

A naive tokenizer sees spaces and splits them. The result:

Input:   "اس نے کتاب خانہ بنایا"
                ↑ ↑
         space between compound components

Wrong:   ['اس', 'نے', 'کتاب', 'خانہ', 'بنایا']
         (5 tokens — "library" is split into "book" + "place")

Right:   ['اس', 'نے', 'کتاب‌خانہ', 'بنایا']
         (4 tokens — "library" is one semantic unit)

The consequences ripple into every downstream NLP task:

Task	What breaks
Search	`کتاب خانہ` doesn't match `کتاب‌خانہ` — zero results
NER	`امورِ خانہ داری` (household affairs) split into 3 unrelated tokens
Sentiment	`بے عزت` (disrespectful) vs `بے` + `عزت` — polarity lost
Translation	`رنگ برنگے` (colorful) translated as "color" + unknown
Word count	Every compound inflates the count with phantom tokens

Why this is genuinely hard

Urdu compound words span four different morphological strategies simultaneously:

Strategy 1 — Affix-based: One word contains a known derivational morpheme (prefix or suffix):

کتاب + خانہ   →  library   (خانہ = "place of" suffix)
بے + عزت      →  disrespectful  (بے = "without" prefix)  
خوش + قسمت   →  fortunate  (خوش = "well" prefix)
کتاب + داری   →  librarianship  (داری = "keeping" suffix)

Strategy 2 — Izafat: A grammatical linking marker appears in the text, written or implied:

کتابِ حسنہ    (the good book)  — Zer mark (◌ِ) on first word
روحِ رواں     (driving spirit) — Hamza-above (◌ٔ) marker
علم و عمل     (knowledge and practice) — Vav-e-atf (و) connector

Strategy 3 — Lexical: Neither word is morphologically special. You simply have to know these pairs:

محنت مشقت     (hard work — synonym compound)
رنگ برنگے     (colorful — echo compound)
صبر شکر       (patient gratitude — near-synonym pair)
انسائیکلوپیڈیا آف اسلام  (3-word fixed title)

Strategy 4 — Chains: Three or more words where each link is independently valid:

امورِ خانہ داری  (household affairs — 3 words)
↑       ↑   ↑
izafat  affix  suffix

Decomposition:
امورِ + خانہ  →  izafat compound
خانہ + داری  →  affix compound
Merged:  امورِ خانہ داری  →  one 3-word compound

No statistical model trained on general text reliably covers all four strategies. They operate at different linguistic levels and require different detection mechanisms.

The approach: three deterministic layers

Every other Urdu compound detection library (where one even exists) treats this as a machine learning problem. They feed training data into statistical models and hope the probabilities align.

That means:

Results change unpredictably between corpus versions
You cannot explain why a pair was or wasn't detected
Edge cases (literary izafat, 3-word expressions, echo words) fail silently
No deterministic guarantee across identical inputs

urdu-tools takes the opposite approach. Every detection is grounded in one of three verifiable, explainable rules:

Raw text
   │
   ├─► Layer 1 — Affix (UAWL)
   │       100+ known Urdu prefix/suffix morphemes
   │       خانہ  گاہ  پرست  بے  نا  خوش  شب  غم  …
   │
   ├─► Layer 2 — Izafat
   │       zer mark (◌ِ) · hamza-above (◌ٔ) · vav-e-atf (و)
   │       کتابِ حسنہ · روحِ رواں · علم و عمل
   │
   └─► Layer 3 — Lexicon
           3,262 root entries · N-word tails · greedy longest-match
           محنت مشقت · رنگ برنگے · انسائیکلوپیڈیا آف اسلام
               │
               └─► Span chaining
                       امورِ خانہ  +  خانہ داری  →  امورِ خانہ داری

The same input always produces the same output, always with a reason.

This is the first open-source implementation of deterministic, multi-layer, N-gram Urdu compound detection in any language.

Introducing urdu-tools

github.com/iamahsanmehmood/urdu-tools

A production-quality, zero-dependency Urdu text processing library. Available for TypeScript/JavaScript and C#/.NET, with identical APIs in both.

npm install @iamahsanmehmood/urdu-tools

dotnet add package UrduTools.Core

392 tests passing. 85 C# tests. 90%+ coverage enforced in CI.

The compound detection API

import {
  detectCompounds,
  joinCompounds,
  splitCompounds,
  isCompound
} from '@iamahsanmehmood/urdu-tools/compound'

Detecting compounds

// Layer 1: Affix — خانہ is a known place-suffix
detectCompounds('کتاب خانہ بہت اچھا ہے')
// → [{
//     text: 'کتاب خانہ',
//     type: 'affix',
//     components: ['کتاب', 'خانہ'],
//     start: 0,
//     end: 1
//   }]

// Layer 1: Affix — بے is a known privative prefix
detectCompounds('بے عزت آدمی نہیں چاہیے')
// → [{ text: 'بے عزت', type: 'affix', components: ['بے', 'عزت'], ... }]

// Layer 2: Izafat — standalone و (vav-e-atf) between content words
detectCompounds('علم و عمل ضروری ہے')
// → [{ text: 'علم و عمل', type: 'izafat', components: ['علم', 'و', 'عمل'], ... }]

// Layer 3: Lexicon — echo compound, neither word is an affix
detectCompounds('رنگ برنگے پھول کھلے ہیں')
// → [{ text: 'رنگ برنگے', type: 'lexicon', components: ['رنگ', 'برنگے'], ... }]

// Lexicon: synonym compound
detectCompounds('محنت مشقت کے بغیر کامیابی نہیں')
// → [{ text: 'محنت مشقت', type: 'lexicon', ... }]

// 3-word chain: izafat (zer on امورِ) + affix (داری suffix on خانہ)
detectCompounds('امورِ خانہ داری چلانا مشکل ہے')
// → [{ text: 'امورِ خانہ داری', type: 'affix', components: ['امورِ', 'خانہ', 'داری'], ... }]

// 3-word lexicon entry: greedy longest-match wins over any 2-word overlap
detectCompounds('انسائیکلوپیڈیا آف اسلام کا حوالہ')
// → [{ text: 'انسائیکلوپیڈیا آف اسلام', type: 'lexicon', ... }]

The pipeline: join before tokenize

The critical downstream use case — bind compounds before tokenizing:

import { joinCompounds } from '@iamahsanmehmood/urdu-tools/compound'
import { tokenize } from '@iamahsanmehmood/urdu-tools'

const text = 'کتاب خانہ میں علم و عمل کی کتابیں ہیں'

// Without compound joining — naive tokenizer splits everything
tokenize(text)
// → ['کتاب', 'خانہ', 'میں', 'علم', 'و', 'عمل', 'کی', 'کتابیں', 'ہیں']
//    ↑ split!                 ↑ split!

// With compound joining — semantic integrity preserved
const joined = joinCompounds(text)
// → 'کتاب‌خانہ میں علم‌و‌عمل کی کتابیں ہیں'
//          ↑ ZWNJ (invisible, prevents tokenizer split)

tokenize(joined)
// → ['کتاب‌خانہ', 'میں', 'علم‌و‌عمل', 'کی', 'کتابیں', 'ہیں']
//    ↑ one token            ↑ one token  ✓

The ZWNJ (Zero Width Non-Joiner, U+200C) is invisible but meaningful — the tokenizer sees it and keeps the word intact.

Pair-level check

isCompound('کتاب', 'خانہ')    // → { matched: true,  type: 'affix'   }
isCompound('محنت', 'مشقت')    // → { matched: true,  type: 'lexicon' }
isCompound('اخلاقِ', 'حسنہ')  // → { matched: true,  type: 'izafat' }
isCompound('اچھا', 'آدمی')    // → { matched: false, type: null      }

Fine-grained control

// Use only specific layers
detectCompounds(text, { affix: true, izafat: false, lexicon: false })
detectCompounds(text, { affix: false, izafat: true, lexicon: true })

// Choose the binder character for joinCompounds
joinCompounds(text)                      // ZWNJ U+200C (default, invisible)
joinCompounds(text, { binder: 'nbsp' })  // Non-breaking space (visible)
joinCompounds(text, { binder: 'wj' })   // Word Joiner U+2060 (never line-breaks)

// Inverse — split back to spaces
splitCompounds('کتاب‌خانہ')  // → 'کتاب خانہ'

The normalization pipeline

A 12-layer normalization pipeline — the foundation that every other module builds on.

import { normalize, fingerprint } from '@iamahsanmehmood/urdu-tools'

Layer	What it does	Default
1 — NFC	Unicode canonical form	✅
2 — NBSP	Non-breaking space → regular space	✅
3 — Alif Madda	`آ` → `آ` (precomposed)	✅
4 — Numerals	`٠–٩` and `۰–۹` → ASCII `0–9`	✅
5 — Zero-width	Strip ZWNJ, ZWJ, soft hyphen	✅
6 — Diacritics	Strip zabar, zer, pesh, shadda, sukun, tanwin	✅
7 — Honorifics	Strip Islamic honorific signs (ؐ ؑ ؒ ؓ ؔ)	✅
8 — Hamza	`أ` → `ا`, `ؤ` → `و`	✅
9 — Kashida	Strip tatweel U+0640	❌
10 — Presentation forms	Map U+FB50–FEFF to base chars	❌
11 — Punctuation trim	Strip leading/trailing non-letter chars	❌
12 — Char normalize	Arabic look-alikes → correct Urdu codepoints	❌

normalize('عِلمٌ')                    // 'علم'  (layers 1–6: diacritics stripped)
normalize('آ')             // 'آ'    (layer 3: Alif + Madda → precomposed)
normalize('علم‌ہے')             // 'علمہے' (layer 5: ZWNJ stripped)
normalize('نبیؐ')                    // 'نبی'  (layer 7: honorific stripped)

// Full normalization for search indexing
normalize(userInput, {
  kashida: true,
  presentationForms: true,
  punctuationTrim: true,
  normalizeCharacters: true,   // ي → ی, ك → ک, ه → ہ
})

The fingerprint function

For client-side word comparison without database round-trips:

fingerprint('عِلمٌ') === fingerprint('عَلم')   // true (both normalize to 'علم')
fingerprint('نبیؐ') === fingerprint('نبی')     // true (honorific stripped)
fingerprint('علم‌') === fingerprint('علم') // true (ZWNJ stripped)

We use this in HamaariUrdu to compare user input against stored words in a 110,000+ word dictionary without needing a round-trip to the database for every keystroke.

The Arabic–Urdu confusion problem

This is the single most common source of silent failures in Urdu software, and no existing library addressed it.

Three character pairs are visually identical in Naskh fonts but are different Unicode code points:

Visual	Arabic codepoint	Urdu codepoint	Common source
ی	ي U+064A	ی U+06CC	Arabic-layout keyboards, Arabic websites
ک	ك U+0643	ک U+06A9	Arabic-layout keyboards
ہ	ه U+0647	ہ U+06C1	Arabic text pasted into Urdu context

A user searching for ہے typed with Arabic ه finds zero results in a database that stored it with Urdu ہ. Both look identical on screen. No error. No warning. Zero results.

import { normalizeCharacters } from '@iamahsanmehmood/urdu-tools'

normalizeCharacters('ي')  // → 'ی'  (U+064A → U+06CC)
normalizeCharacters('ك')  // → 'ک'  (U+0643 → U+06A9)
normalizeCharacters('ه')  // → 'ہ'  (U+0647 → U+06C1)

// Apply before storage or search indexing:
normalize(userInput, { normalizeCharacters: true })

Progressive search matching

The search module tries 9 progressively aggressive normalization layers until it finds a match — or returns false with full diagnostic info.

import { match, fuzzyMatch, getAllNormalizations } from '@iamahsanmehmood/urdu-tools'

match('عِلمٌ', 'علم')
// → { matched: true, layer: 'strip-diacritics', normalizedQuery: 'علم', normalizedTarget: 'علم' }

match('نبیؐ', 'نبی')
// → { matched: true, layer: 'strip-honorifics', ... }

match('أحمد', 'احمد')
// → { matched: true, layer: 'normalize-hamza', ... }

match('کتاب', 'علم')
// → { matched: false, layer: null, ... }

For database lookups, getAllNormalizations() returns every normalized form to try:

const forms = getAllNormalizations('عِلمٌ')
// → ['عِلمٌ', 'عِلم', 'علم', ...]  (from most specific to most aggressive)

for (const form of forms) {
  const result = await db.get(form)
  if (result) return result
}

Fuzzy matching uses Levenshtein + LCS hybrid (threshold 0.5):

fuzzyMatch('کتاب', ['کتابیں', 'کتب', 'علم'])
// → { candidate: 'کتابیں', score: ~0.7 }

Numbers — South Asian scale with bigint

The South Asian number system has named units that don't exist in Western mathematics:

Urdu	Value
ہزار	1,000
لاکھ	100,000
کروڑ	10,000,000
ارب	1,000,000,000
کھرب	1,000,000,000,000
نیل	1,000,000,000,000,000

The entire module uses bigint throughout — South Asian numbers exceed Number.MAX_SAFE_INTEGER.

import { numberToWords, formatCurrency, toUrduNumerals, wordsToNumber } from '@iamahsanmehmood/urdu-tools'

numberToWords(0n)                      // 'صفر'
numberToWords(100n)                    // 'ایک سو'
numberToWords(100_000n)                // 'ایک لاکھ'
numberToWords(10_000_000n)             // 'ایک کروڑ'
numberToWords(1_000_000_000_000_000n)  // 'ایک نیل'

// Ordinals with gender agreement
numberToWords(1n, { ordinal: true, gender: 'masculine' })  // 'پہلا'
numberToWords(1n, { ordinal: true, gender: 'feminine' })   // 'پہلی'
numberToWords(11n, { ordinal: true, gender: 'masculine' }) // 'گیارہواں'
numberToWords(11n, { ordinal: true, gender: 'feminine' })  // 'گیارہویں'

// Currency
formatCurrency(505.50, 'PKR')  // 'پانچ سو پانچ روپے پچاس پیسے'
formatCurrency(1000, 'INR')    // 'ایک ہزار روپے'

// Numeral conversion
toUrduNumerals(2024)    // '۲۰۲۴'

// Inverse — parse words back to number
wordsToNumber('ایک کروڑ')     // 10_000_000n
wordsToNumber('پانچ سو پانچ') // 505n

Canonical Urdu sorting

No database and no JavaScript runtime has native Urdu collation. The 39-letter Urdu alphabet order:

ء ا ب پ ت ٹ ث ج چ ح خ د ڈ ذ ر ڑ ز ژ س ش ص ض ط ظ ع غ ف ق ک گ ل م ن ں و ہ ھ ی ے

import { sort, compare, sortKey } from '@iamahsanmehmood/urdu-tools'

sort(['ے', 'ا', 'ک', 'ب'])           // → ['ا', 'ب', 'ک', 'ے']
sort(['زبان', 'اردو', 'بہترین'])      // → ['اردو', 'بہترین', 'زبان']

// Use compare() as a comparator for any sorting context
['ے', 'ا', 'ک'].sort(compare)        // → ['ا', 'ک', 'ے']

// sortKey() for indexing — diacritics stripped before key generation
sortKey('پاکستان')   // '030003091102280814'
// عِلم and عَلم sort to the same position

In C# it implements IComparer<string> for native LINQ integration:

using UrduTools.Core.Sorting;

var words = new[] { "ے", "ا", "ک", "ب" };
var sorted = words.OrderBy(w => w, new UrduComparer()).ToList();
// ["ا", "ب", "ک", "ے"]

Unicode-aware tokenization

The tokenizer handles the edge cases that matter in real Urdu text:

import { tokenize, sentences, ngrams } from '@iamahsanmehmood/urdu-tools'

tokenize('پاکستان ایک خوبصورت ملک ہے')
// → [
//   { text: 'پاکستان', type: 'urdu-word' },
//   { text: 'ایک',     type: 'urdu-word' },
//   { text: 'خوبصورت', type: 'urdu-word' },
//   { text: 'ملک',     type: 'urdu-word' },
//   { text: 'ہے',      type: 'urdu-word' },
// ]

// Sentence splitting — on ۔ (U+06D4) ؟ ! but NOT on ، or ؛
sentences('پہلا جملہ۔ دوسرا جملہ؟ تیسرا جملہ!')
// → ['پہلا جملہ', 'دوسرا جملہ', 'تیسرا جملہ']

// The tokenizer preserves ZWNJ within words —
// so joinCompounds() output is one token per compound

Key edge cases handled:

Izafat Kasra (U+0650) at word boundaries is not treated as a split point
ZWNJ-bound compounds (output of joinCompounds()) are kept as single tokens
Mixed Urdu/Latin text is classified per-token

Transliteration — 18 aspirated digraphs

import { toRoman, fromRoman } from '@iamahsanmehmood/urdu-tools'

toRoman('پاکستان')   // 'pakistan'
toRoman('بھارت')     // 'bharat'
toRoman('چھوٹا')     // 'chhota'

Digraph rules (left-to-right FSM, digraph priority):

Urdu	Roman	Urdu	Roman
بھ	bh	پھ	ph
تھ	th	ٹھ	Th
جھ	jh	چھ	chh
دھ	dh	ڈھ	Dh
کھ	kh	گھ	gh

fromRoman('pakistan')  // → 'پاکستان' (trie-based longest-prefix match)
fromRoman('bharat')    // → 'بھارت'

InPage encoding — decoding 30 years of Urdu archives

InPage was the dominant Urdu desktop publishing tool for decades. Millions of documents — newspapers, books, government archives — exist only in InPage format. The library decodes all three versions:

import { decodeInpage, detectEncoding } from '@iamahsanmehmood/urdu-tools'

// Auto-detect InPage version and decode
const result = decodeInpage(buffer, 'auto')
// result.paragraphs → string[]  (Unicode Urdu text)
// result.version   → 'v1' | 'v2' | 'v3'

// Explicit version
decodeInpage(buffer, 'v1')  // 0x04-prefix byte-pair encoding (old InPage)
decodeInpage(buffer, 'v3')  // UTF-16LE with paragraph markers

// Detect encoding from buffer alone
detectEncoding(buffer)
// → 'utf-8' | 'utf-16le' | 'windows-1256' | 'inpage-v1v2' | 'inpage-v3' | 'unknown'

String utilities

import { reverse, truncate, wordCount, charCount,
         extractUrdu, decodeHtmlEntities } from '@iamahsanmehmood/urdu-tools'

// Reverse word order (not characters — preserves Arabic shaping)
reverse('پاکستان ہندوستان')      // → 'ہندوستان پاکستان'

// Truncate at word boundary
truncate('یہ ایک بہت لمبا جملہ ہے', 10)  // → 'یہ ایک...'

// Count grapheme clusters (correct for combining diacritics)
charCount('عِلم')   // → 3  (ع+ِ = 1 cluster, ل, م)

// Extract Urdu/Arabic segments from mixed text
extractUrdu('The word علم means knowledge')  // → ['علم']

// Decode HTML entities BEFORE normalize() — critical for TinyMCE/Quill content
decodeHtmlEntities('کتاب&rsquo;خانہ')  // → 'کتاب’خانہ'
decodeHtmlEntities('علم&nbsp;ہے')      // → 'علم ہے'

That last one (decodeHtmlEntities) is the fix for the TinyMCE bug mentioned at the top. Always call it before normalizing text that came from a rich text editor.

Script and character analysis

import { isUrduChar, getScript, classifyChar, isRTL, getUrduDensity } from '@iamahsanmehmood/urdu-tools'

isUrduChar('پ')  // true  — U+067E is Urdu-specific
isUrduChar('ب')  // false — U+0628 is shared with Arabic
isUrduChar('۱')  // true  — U+06F1 Urdu numeral

getScript('پاکستان')          // 'urdu'
getScript('مرحبا')             // 'arabic'
getScript('Hello پاکستان')    // 'mixed'

classifyChar('پ')   // 'urdu-letter'
classifyChar('َ')   // 'diacritic'
classifyChar('۱')   // 'numeral'

isRTL('پاکستان')               // true
getUrduDensity('پاکستان زندہ') // 0.28

C#/.NET — identical API, zero dependencies

Every function is available in UrduTools.Core with the same behavior. The C# package mirrors the TypeScript structure exactly.

using UrduTools.Core.Normalization;
using UrduTools.Core.Compound;
using UrduTools.Core.Numbers;
using UrduTools.Core.Sorting;
using UrduTools.Core.Search;

// Normalize
UrduNormalizer.Normalize("عِلمٌ");                          // "علم"
UrduNormalizer.Normalize("علم‌");                      // "علم"

// Compound detection
var spans = CompoundDetector.DetectCompounds("کتاب خانہ میں");
// spans[0].Text == "کتاب خانہ"
// spans[0].Type == CompoundType.Affix

// Numbers
NumberToWords.Convert(10_000_000);  // "ایک کروڑ"
NumberToWords.Convert(1, new NumberOptions { Ordinal = true, Gender = Gender.Feminine });  // "پہلی"

// Sort
var sorted = new[] { "ے", "ا", "ک", "ب" }
    .OrderBy(w => w, new UrduComparer())
    .ToList();  // ["ا", "ب", "ک", "ے"]

// Progressive normalization for DB lookup
foreach (var form in UrduMatcher.GetAllNormalizations(userInput))
{
    var result = await db.LookupAsync(form);
    if (result is not null) return result;
}

// Match
UrduMatcher.Match("عِلمٌ", "علم").Matched;  // true, layer: StripDiacritics

Academic foundation

The compound word detection module was built on peer-reviewed Urdu linguistics research. These three works directly informed the architecture:

Jabbar, A. (2016). "Urdu Compound Words Manufacturing a State of Art."
Provides the Urdu Affix Word List (UAWL) — the definitive catalog of Urdu derivational morphemes. The 100+ affix morphemes in Layer 1 (AFFIX_SET, PREFIX_SET, SUFFIX_SET) are drawn from this work.

Rahman, M. "A Linguistic Classification of Urdu Compound Words."
Informed the typological distinctions between compound categories — specifically the Perso-Arabic vs. native Urdu origin split and vav-e-atf chain patterns. Shaped the CompoundType taxonomy and izafat heuristics.

"High Performance Stemming Algorithm to Handle Multi-Word Expressions."
Motivated the joinCompounds() + tokenize() pipeline design — the paper demonstrates that semantic integrity is best preserved by preventing erroneous splits at the input boundary, not by post-processing token sequences. Also reinforced N-gram scanning over bigram-only approaches.

Used in production

This library is not a side project. It runs in three production systems:

System	Type
HamaariUrdu	Urdu language learning platform — normalization, search, compound detection, numbers
Pakistan Academy of Letters	Government literary institution — normalization, search, sorting
Digital Library of PAL	Government digital Urdu archive — normalization, search, encoding

HamaariUrdu was the origin — the library was extracted from production code where these problems were first encountered and solved. PAL and DLP integrated later for their Urdu text search and archiving systems.

Live Playground

Every function is interactive at iamahsanmehmood.github.io/urdu-tools.

The playground includes compound reporting built-in: if you find a compound the detector misses, or a pair it wrongly detects, you can report it directly from the UI — a pre-filled GitHub issue opens in one click.

Contributing

The compound lexicon (3,262 roots, expandable) is the highest-impact area for non-developer contributions. If you know Urdu, you can contribute without writing code:

// packages/urdu-js/src/compound/lexicon-data.ts
// Format: ['rootWord', new Set(['tail1', 'tail2'])]

['محنت', new Set(['مشقت'])],
['علم', new Set(['و ہنر', 'و عمل', 'کیمیا'])],
['انسائیکلوپیڈیا', new Set(['آف اسلام'])],

Full guide in CONTRIBUTING.md.

GitHub: github.com/iamahsanmehmood/urdu-tools

اردو سافٹ ویئر کو بہتر بنانے میں ہمارا ساتھ دیں۔
Help us make Urdu software better.

Tags: #urdu #nlp #typescript #dotnet #opensource

Building a Multi-Terminal Restaurant POS with C# .NET — Architecture & Lessons

Ahsan Mehmood — Mon, 09 Mar 2026 03:33:29 +0000

Building a Point-of-Sale system sounds straightforward until you realize it needs to handle multiple terminals, thermal printers, kitchen displays, real-time table tracking, and never lose a transaction — even when the network drops.

I built RestoCare+ — a multi-terminal restaurant POS system — and in this post, I'll walk through the architecture decisions, the problems I ran into, and what I'd do differently.

Background

I spent 4+ years working as a supervisor at a restaurant in Islamabad. I saw firsthand how terrible most POS systems were — slow, unreliable, confusing for staff, and impossible to maintain.

When I transitioned into software development, this was the first real product I wanted to build. Not because it was technically exciting, but because I deeply understood the problem.

Tech Stack

Language: C#
Framework: .NET Framework (WinForms for UI)
Database: SQL Server
Printing: ESC/POS commands via Windows Services
Architecture: Client-Server with centralized SQL database

High-Level Architecture

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  Terminal 1   │    │  Terminal 2   │    │  Terminal 3   │
│  (Cashier)    │    │  (Cashier)    │    │  (Manager)    │
└──────┬───────┘    └──────┬───────┘    └──────┬───────┘
       │                   │                   │
       └───────────┬───────┴───────────────────┘
                   │
           ┌───────┴───────┐
           │   SQL Server   │
           │   (Central DB) │
           └───────┬───────┘
                   │
       ┌───────────┼───────────┐
       │           │           │
┌──────┴──┐  ┌────┴────┐  ┌───┴──────┐
│ Thermal  │  │ Kitchen  │  │ Receipt  │
│ Printer 1│  │ Display  │  │ Printer  │
└─────────┘  └─────────┘  └──────────┘

Key Design Decisions

1. Centralized Database, Not Peer-to-Peer

Every terminal connects to a single SQL Server instance. I considered SQLite per terminal with sync, but restaurants can't tolerate eventual consistency — if Terminal 1 marks Table 5 as occupied, Terminal 2 needs to see that immediately.

// Connection string points to central SQL Server
string connectionString = ConfigurationManager
    .ConnectionStrings["RestoCareDB"].ConnectionString;

2. Real-Time Table Management

The table management system uses a polling approach to keep all terminals in sync. Every terminal refreshes the floor plan every few seconds.

// Table status refresh timer
private Timer _tableRefreshTimer;

private void InitializeTableSync()
{
    _tableRefreshTimer = new Timer(3000); // 3-second interval
    _tableRefreshTimer.Elapsed += RefreshTableStatuses;
    _tableRefreshTimer.Start();
}

private void RefreshTableStatuses(object sender, ElapsedEventArgs e)
{
    var tables = _tableRepository.GetAllWithStatus();
    UpdateTableUI(tables);
}

Why polling instead of SignalR/WebSockets? Simplicity. In a restaurant with 3-5 terminals on a local network, a 3-second poll is good enough and dramatically simpler to debug when something goes wrong at 9 PM on a Friday night.

3. Thermal Printing via Windows Service

Thermal receipt printers speak ESC/POS — a binary command language. I built a dedicated Windows Service (IMS Print Service) that handles all print jobs:

// ESC/POS command to print bold text
byte[] boldOn = new byte[] { 0x1B, 0x45, 0x01 };
byte[] boldOff = new byte[] { 0x1B, 0x45, 0x00 };
byte[] centerAlign = new byte[] { 0x1B, 0x61, 0x01 };

public void PrintReceipt(Order order)
{
    var printer = new RawPrinter(_printerName);

    printer.Write(centerAlign);
    printer.Write(boldOn);
    printer.WriteText("RESTAURANT NAME\n");
    printer.Write(boldOff);

    foreach (var item in order.Items)
    {
        printer.WriteText(
            $"{item.Name,-20} x{item.Qty,3} {item.Total,8:C}\n"
        );
    }

    printer.WriteText($"\nTOTAL: {order.Total:C}\n");
    printer.CutPaper();
}

Why a Windows Service? Two reasons:

The print service runs independently — even if the POS UI crashes, queued prints still go through.
Multiple terminals can send print jobs to the same service, which queues them to avoid conflicts.

4. Kitchen Display Integration

When a waiter submits an order, it needs to appear on the kitchen display instantly. The kitchen display is a separate WinForms app running on a screen in the kitchen:

// Kitchen display polls for new orders
public List<KitchenOrder> GetPendingOrders()
{
    using (var context = new RestoCareContext())
    {
        return context.Orders
            .Where(o => o.Status == OrderStatus.Pending 
                     || o.Status == OrderStatus.InProgress)
            .OrderBy(o => o.CreatedAt)
            .Include(o => o.Items)
            .ToList();
    }
}

Kitchen staff tap items as they're prepared, and the waiter's terminal updates in real-time showing which items are ready.

5. Handling the Offline Scenario

What happens when the network drops? This is critical in restaurants — you can't stop taking orders because WiFi went down.

My approach: local queue with retry.

// If SQL Server is unreachable, queue locally
public void SubmitOrder(Order order)
{
    try
    {
        _orderRepository.Save(order);
        _kitchenService.NotifyNewOrder(order);
    }
    catch (SqlException)
    {
        _localQueue.Enqueue(order);
        _logger.Warn("DB unreachable — order queued locally");
        // Background task retries every 10 seconds
    }
}

Mistakes I Made

1. Not planning for menu changes

My initial schema had menu items tightly coupled to orders. When the restaurant changed prices or renamed dishes, it broke historical reports. Fix: I added a snapshot of the item at order time — OrderItem stores its own PriceAtTime and NameAtTime.

2. Underestimating receipt formatting

Thermal printers have 42-character line width (for 80mm paper). I spent more time formatting receipts than I expected. Arabic/Urdu text support was a whole adventure.

3. Not building user management from day one

I added multi-user roles (cashier, manager, admin) later, and retrofitting permissions into an existing system is painful. Always plan roles early.

What I'd Do Differently

Use .NET 8 instead of .NET Framework — better performance, cross-platform
Add offline-first architecture from the start, not as an afterthought
Build a web dashboard alongside the desktop app for owners to check reports remotely
Use message queues (RabbitMQ or even a simple one) instead of polling for kitchen display

Results

RestoCare+ is running in production at real restaurants. It handles:

✅ 3-5 terminals simultaneously
✅ Thermal receipt printing with proper formatting
✅ Kitchen display with real-time order updates
✅ Table management with status tracking
✅ Daily sales reports and analytics
✅ Menu management with category organization

Key Takeaways

Domain knowledge is your unfair advantage. My 4 years in a restaurant made me a better POS developer than someone with 10 years of pure coding.
Polling is fine for local networks. Don't over-engineer with WebSockets when 3-second polling works perfectly.
Thermal printing is harder than it looks. Budget extra time for this.
Build the boring stuff well. Boring features like user roles, audit logs, and error handling are what separate a demo from a product.

I'm Ahsan Mehmood — a Full-Stack Developer and Co-Founder of XechTech. I share what I learn from building real-world software. Follow for more .NET, Flutter, and AI content.

Connect: LinkedIn · GitHub · XechTech

From Restaurant Supervisor to Technical Founder: Shipping 38+ Projects in 5 Years

Ahsan Mehmood — Mon, 09 Mar 2026 03:25:50 +0000

Hey Dev.to 👋 I'm Ahsan Mehmood — a Full-Stack Developer and Co-Founder of XechTech, based in Islamabad, Pakistan.

My Journey

In 2017, I was working as a restaurant supervisor. By 2021, I had pivoted into software development full-time. Today, I've shipped 38+ production projects across 8+ organizations, serving clients in Pakistan, the US, and Australia.

What I Build

My core stack is .NET/C#, but I work across the full spectrum:

🖥️ Desktop: Multi-terminal POS systems, payroll, accounting tools (C#, .NET, SQL Server)
📱 Mobile: Cross-platform apps with Flutter (Booktionary, EstiMate Pro, DLP App)
🌐 Web: React, Laravel, Node.js, TypeScript (pal.gov.pk, xechtech.com)
🤖 AI: AutoCAD AI Agent, Gemini PC-Commander, LLM-powered workflows
🏗️ Engineering: 7+ structural tools for RPEQ-certified projects in Australia

My Company: XechTech

I co-founded XechTech in 2021 with my partner Aaqib Saleem. We build high-end software solutions — from RestoCare+ (a restaurant POS system with thermal printing and kitchen displays) to AI-powered PDF automation tools.

Key Projects

Project	What It Does	Tech
RestoCare+ POS	Multi-terminal restaurant POS	C#, .NET, SQL Server
EstiMate Pro	AI-powered PDF automation	Flutter, Dart
Engineering Suite	7+ structural analysis tools	C#, .NET, AutoCAD
PAL Website	Government website	PHP, Laravel, Flutter
Booktionary	Dictionary & book app	Flutter, SQLite
AutoCAD AI Agent	AI-generated floor plans	Python, Gemini API

What I've Learned

The biggest lesson from shipping 38+ projects: Solve real problems for real people. The fanciest tech stack means nothing if it doesn't solve a pain point.

I built RestoCare+ because I spent 4 years in a restaurant and knew exactly what was broken. I built engineering tools because construction firms in Australia needed calculations done faster. Every successful project started with understanding the problem deeply.

What's Next

I'm currently focused on:

AI integration into traditional business software
Growing XechTech's client base internationally
Sharing what I've learned through writing here on Dev.to

If you're a developer in Pakistan building your career, or if you're transitioning into tech from another field — I'd love to connect. Drop a comment or find me on LinkedIn 🤝

Follow me for posts about .NET, Flutter, AI integration, and building software businesses from Pakistan.