DoraDoriApparel manufacturing
DoraDori is a garment ERP on FastAPI and PostgreSQL, integrated with Zoho and the client's internal CRM. Two published reads carry most of its integration surface: item summary, covering bill of materials and stock, and fabric stock valuation. Garment manufacturing ERP work lives or dies on cut order and marker software, because that is where fabric turns into cost.
Build fingerprint
Where it runs, how we engaged, and what it was built on.
Technologies
What makes this problem genuinely hard - before any client name enters the page.
There is no flat item master in apparel, there are three levels. A style carries the tech pack, bill of materials, cost sheet and season code. Style and colour, the colourway, is what the trade calls the SKU and what merchandisers plan at. Only style, colour and size physically exists, so it is the only countable level. A shirt in 12 colours and 7 sizes is 1 style, 12 SKUs, 84 variants, and denim multiplies faster because size there is waist by inseam.
Demand across a size run follows a curve, say 1-2-3-3-2-1. Buy against the wrong one and units remain but not in sellable sizes, so stock reads healthy while the order cannot be filled. Roll that to style level and the problem vanishes from the report, which is why the stock view stays at variant level.
Fabric is the largest line on most cost sheets, and its number comes off the marker, the nesting of pattern pieces across the cuttable width. Consumption is size dependent, so one figure per garment is already wrong, and wastage compounds: end loss, splice loss, relaxation shrinkage, cutting waste, sewing rejects. Labour costs in standard allowed minutes against a target line efficiency.
After cutting, pieces are numbered and bundled, and the bundle ticket is what the floor tracks and often what an operator is paid on. Shade must survive the cut too: every panel of one garment from the same dyelot, or the piece is a reject whatever the ledger says.
Three years of dedicated resources is long enough that an ERP stops being a project and becomes the thing other systems ask questions of. Two of those questions matter most: what a style is made of and what is on hand, which is the item summary, and what fabric is worth rather than how much there is, which is the fabric stock valuation. Both are read from outside, so they are a contract rather than an internal function. The books are the third boundary: accounting in Zoho, commercial context in an internal CRM, and the ERP has to agree with both without becoming either.
FastAPI over PostgreSQL, owned end to end rather than added as a module inside a general platform. Three levels, a size dimension and yield driven costing are expensive to bolt onto a flat item master.
One read answers both halves: what a style consumes, and what exists underneath it. The BOM hangs off the style and the count sits at variant, so the summary crosses that boundary rather than pretending the catalogue is flat.
Fabric behaves like bulk material, not a countable item: rolls in, issued against a marker, remnants back. This read is what other systems take when fabric has to be money rather than metres.
Accounting reconciles against Zoho, commercial records against the CRM, so the ERP holds the physical truth and neither has to be rebuilt inside it.
Tradeoffs
Every choice closed off something else. Those costs are stated, not hidden.
Instead of: Apparel as a vertical module inside a general product. Three levels, size curves and yield costing touch the item master, the stock model and the costing engine at once, forcing those changes onto products with no use for them.
What we acceptedTenancy, access control and deployment are solved again rather than inherited, and two codebases get patched instead of one.
Instead of: Separate BOM and stock endpoints, each caller joining them. The join is where the hierarchy knowledge lives, and pushing it out spreads apparel rules into systems with no reason to hold them.
What we acceptedA wider contract that moves when either side does, and a heavier read than a plain stock lookup.
Instead of: One stock view carrying value for everything. Fabric and finished goods do not value the same way, and a merged view is defensible for neither.
What we acceptedTwo views that have to agree, and a reconciliation every time they do not.
Reusable
Generic ERP posts one material variance against the order. Apparel needs five: different owners, different fixes, and a combined figure tells nobody which to work on.
| Variance | What it isolates | Where the number comes from | What you change |
|---|---|---|---|
| Fabric yield | Consumption against cost sheet | Issue against cut order BOM | Costing assumption, or the BOM |
| Marker | Nesting efficiency | Marker report per size ratio | Marker making, ratio, fabric width |
| Shrinkage | Relaxation loss | Relaxed against received length | Fabric spec, supplier, relaxation time |
| Labour efficiency | Minutes earned against worked | Standard allowed minutes against line output | Line balancing, skill mix |
| Rework | Cost of pieces returned | Rejects logged at the operation | The operation, not the order |
If a costing system cannot say which of these lost the money, the post mortem is an argument about opinions.
Delivery
Capabilities delivered and the scope of the build - not results attributed to it.
Capabilities
Scope
Scope of the build, not results attributed to it.
Bring us the part you think is hardest.
Item summary and fabric valuation are consumed outside DoraDori, so altering either shape alters somebody else's system. Neither moves on the ERP's own schedule.
Zoho holds the books, the CRM the commercial record. When a figure is disputed the ERP is not automatically the winner, and knowing which system settles which question is part of running it.
Not the codebase alone. The product model and costing assumptions: which level each number lives at, and what the valuation counts as issued.
Reflection
The item summary says what is on hand without saying whether it is sellable, because sellable in apparel means a complete size run rather than a total. We would put size run completeness into that read at the start rather than leave each caller to work it out. The second is the Zoho boundary, drawn once early and never revisited, so a handful of figures have two plausible homes and which is authoritative is convention rather than design.
The variant ceiling is rarely the binding constraint, the option count is. Shopify raised its variant limit to 2,048 in October 2025, but the cap of three options per product did not move. Size, colour and one more is the budget, and denim needs waist, inseam, fit and wash.
One read returning what a style is made of and what exists underneath it. The BOM hangs off the style and stock exists only at style, colour and size, so it joins two levels. A flat item lookup cannot answer it.
Because fabric is usually the biggest line in the cost sheet, and the nesting of pattern pieces across the cuttable width decides how much a garment consumes.
Context
Tell us what your operation runs on today.
Real feedback from the people we've proudly partnered with.
Sales Director |Cintas
United States
Zyneto Global Technologies provided excellent project management and technical expertise throughout the engagement. The team was responsive, collaborative, and adaptive, ensuring the project met our expectations and set a strong foundation for future growth.
Founder & CEO |Moneteo
We engaged Zyneto to design and develop a custom web platform for Moneteo, aimed at improving project management, data tracking, and collaboration across internal teams and external partners. Their work included full-stack web development, custom modules for workflow automation, API integration, and comprehensive testing.
CEO |E-Commerce Platform
Overall, their responsiveness and timely deliveries contributed positively to the project's success. The client achieved better data management and quality. The service provider delivered the project on time and ensured prompt responsiveness throughout the engagement. Their innovative approach was outstanding.
