ahmad@abboud.dev · bash
tty1
Last login: just now on ttys001
ahmad@abboud.dev · portfolio shell v1.0
▸ mounting /projects … ok
▸ loading identity … ok
▸ 2 phone lines, 1 timezone, 0 recruiters harmed
 
Ahmad Abboud
Senior Full-Stack Engineer · Tech Lead
I drag factories into the 21st century.
 
You have a shell. Most of it is locked.
Type -h to see what you can run.
// no javascript. the shell is off, but everything it prints is written out beside it.
type -h and hit enter
ahmad@abboud:~$ open texerp

TexERP

Built it all by myself

Full ERP for textile factories with IoT sensors feeding real-time production analytics, planning, inventory, quality control, and manufacturing operations

+300,000 lines of code before coding agents existed100+ database modelshardware on the factory floor
// internal system. no public link, and I won’t fake one. plain-language version

// visuals on request

A textile factory is a supply chain folded in on itself. Yarn comes in by lot and gets warped onto beams. Beams and wefts become production orders on named machines. Cloth comes off raw, goes out to a dye house or a laminator, comes back, gets quality-graded, cut, barcoded, shelved, and eventually shipped against an order that was quoted months earlier in a currency that has since moved. Every one of those steps is a place where physical stock and recorded stock stop agreeing.

TexERP is the system that keeps them agreeing. I built it end to end.

What it covers

Sales. Customers, meeting reports, competitor analysis, feasibility forms, price lists per customer and product, offers with validity windows and payment terms, complaints with the corrective action attached.

Production. Yarn types and stock entries by lot, warp orders against specific machines, weft consumption, production orders that draw from real beams and record what they actually consumed rather than what the recipe said.

Outsourcing. Dye orders and laminating orders, the shipments out, the confirmations back, and reconciliation between what left and what returned.

Stock. A single stock record that carries its lot, meters, kilograms, quality grade, dye colour, warehouse, shelf, barcode, and the stock it originated from, so a roll can be traced back through every process it went through.

Purchasing. Requests with supervisor and purchasing approval, orders, deliveries, materials with a category tree, supplier evaluation scored across ten criteria.

Plus the connective tissue: notifications, an action log, a non-conformity/corrective-action workflow, and reporting.

The schema is the product

Over a hundred Prisma models with the relations to match. That is not incidental complexity: the whole value of an ERP is that the model matches the factory. If stock can’t express “this roll is the dyed output of that raw roll, currently held for a customer, in that warehouse, on that shelf”, then someone keeps a parallel spreadsheet and the system has failed.

Getting that right meant reading the floor, not the requirements document. Nobody could tell me the rules up front; they could only tell me when a screen was wrong.

Talking to machines

Quality-control and cutting stations report through Python services that bridge serial hardware to the backend over WebSockets, packaged with PyInstaller so a station is an executable somebody double-clicks rather than a Python environment somebody maintains. Label and report printing runs through its own service for the same reason.

Honest notes

Three hundred thousand lines, one person, before coding agents existed. The parts I would do differently now are the early ones. The schema learned as I learned the business, and it shows in places. The parts I would keep are the stock model and the decision to make every movement an explicit record rather than a mutation, because that is what makes a discrepancy answerable instead of just visible.

It runs inside a factory. There is no public link, and I’m not going to invent one.

▸ stack

TypeScriptNode.jsPrismaMySQLNext.jsMaterial UITailwindPythonDocker