Skip to content
TECH MANIAC
ALL WORK
TEXTILE MANUFACTURING · ERP

ShAntoTex

An ERP that has been closing a real weaving company's books, without interruption, for over seven months.

7+ months

Continuous production use

3,897

Stock entries recorded

175

Endpoints across 69 screens

ShAntoTex — Sign-in
ShAntoTex — Operations dashboard — figures redacted
ShAntoTex — Customer receivables — names redacted
ShAntoTex — Stock position by customer — names redacted

SIGN-IN

THE PROBLEM

A vertically-integrated weaving operation ran on paper ledgers and spreadsheets. Weaving jobs were costed by hand, weavers were paid per unit against loans nobody could total quickly, and the month-end position was an argument rather than a number.

The constraint that shaped everything: the people entering the data are on a factory floor, not at a desk, and many of them do not type comfortably in English. A system that demanded fast accurate English keyboard entry would simply not be used, and an unused system is worse than the spreadsheets it replaced.

WHAT WE BUILT

PRODUCTION & INVENTORY

  • Stock entries and production registers
  • Weaving job costing
  • Product and department master data

MONEY

  • Cash and bank books across multiple accounts
  • Weaver payments, loans and repayment schedules
  • Payroll and salary ledger
  • Supplier payments and dues
  • Sales billing and customer dues
  • Expenses by head and sub-head
  • Company loans and commercial property rent

CONTROL

  • Role-based permissions with a permission registry
  • A second PIN factor on sensitive operations
  • Revision-and-approval workflow on financial records
  • Full audit trail of every mutation
  • PDF and Excel export across reports

SHAPE OF IT

A deliberate monolith — one application, one database, three worker processes behind a reverse proxy. For a single-tenant system used by a handful of staff on one site, splitting it into services would have added operational surface without buying anything. It is installable as a progressive web app so the factory floor can use it on a phone, including offline.

BANGLA AUDIOSTAFFphone · PWANGINXFLASK3 workersPOSTGRES44 modelsREDISrate limitGEMINIvoice → ledgerSMTP
A DELIBERATE MONOLITH — SPLITTING IT WOULD ADD OPERATIONS WITHOUT BUYING ANYTHING
ONE WAYBOTH WAYSPERIODIC
FlaskPostgreSQLRedisGoogle GeminiPWA

DECISIONS THAT MATTERED

The parts that were not obvious.

01

Staff speak their entries in Bangla

The most-used feature is voice entry: a user speaks an expense in Bengali and it becomes a structured ledger entry, with the account and supplier lists supplied to the model as context so it resolves to real records rather than free text. Input is stripped of control characters and explicitly guarded against prompt injection before it reaches the model — an easy step to skip, and a costly one to skip in a system that writes to the books.

02

No floating point anywhere in the money path

All monetary arithmetic uses decimal values with explicit half-up rounding. Floating point is fine until a trial balance is off by one paisa and nobody can say why, at which point it is the most expensive shortcut in the codebase.

03

Financial records are never edited in place

Changing a posted record goes through a revision request and an approval, so there is always a record of what was changed, by whom, and who agreed to it. In a business where the same person often enters and approves, this is what makes the audit trail worth having.

04

Loan balances update in a single atomic operation

Weaver loan balances are decremented by one database statement triggered on repayment insert, clamped at zero. Reading a balance, subtracting in application code and writing it back would double-decrement under concurrent repayments — which is exactly the kind of bug that surfaces as a weaver being told they owe money they have already paid.

05

Startup schema work is guarded by an advisory lock

Three worker processes start simultaneously and would otherwise race each other applying schema changes. An advisory lock means exactly one does the work and the others wait — a small fix for a failure mode that only appears under real deployment conditions.

06

Time is always Dhaka time

Business dates are computed in Asia/Dhaka rather than taken from the server clock or the database's timezone. A report that silently shifts by six hours puts transactions in the wrong month, and month-end is precisely when nobody has the patience to debug it.

The people entering the data are on a factory floor, not at a desk. A system that demanded fast English typing would simply not be used.

WHERE IT LANDED

  • Over seven months of continuous daily production use, with no rollback to the previous process.
  • 3,897 stock entries, 1,827 bank transactions and 1,233 logged audit actions recorded in the live system.
  • 175 endpoints across 69 screens and 44 data models.
  • Month-end position is now a query rather than a reconstruction.