StylebankApparel wholesale, manufacturing and marketplace retail
Stylebank runs four apparel businesses on one Django codebase, each with its own database, S3 bucket and Redis namespace. It pulls marketplace orders, factory production and accounting into one place, then plans replenishment against it. Apparel platform development at this shape is really wholesale apparel software, with four businesses sharing one schema.
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.
Each business in a group carries its own buyers, factories and books. The cheap option is a tenant column on every table, which holds until one query misses the filter and a company reads a rival's cost sheet. Isolating by database makes it an infrastructure problem instead, and buys per company restore, retention and job windows.
Channel data restates itself. An order cancels after picking, a return lands weeks after the sale, settlement follows on its own cycle with commission attached. Channels do not share vocabulary either: a return to origin is not a customer return, although both reduce the same figure. Ingest that as an append and you double count. Pulls upsert on the channel's identifier and carry a snapshot date, so you can answer what you believed on the day you decided.
You do not replenish finished goods, you replenish the ability to make them. A plan needs rate of sale at style, colour and size, stock at the warehouse and each channel, work in progress on the floor, and fabric on hand including greige not yet dyed. Lead time is a chain: dyeing, cutting, sewing and finishing each hold a queue. B2B and ecom diverge: one plans against an order book and pack ratios, the other against days of cover and a size curve.
A row per style per day per channel per metric compounds quietly, and nothing in the application tells you. You find out when a backup stops fitting its window, or an ALTER becomes an outage rather than a migration. Archiving buys time; the structural fix is to stop mixing an append only fact stream with operational state.
Stylebank is the operating platform for four apparel businesses, each manufacturing, selling wholesale and selling through marketplaces. The commercial picture sat in systems with no reason to talk to each other: channel orders, inventory, returns and GRN in an aggregator fronting five marketplaces; production, defects and costing in a factory ERP; item summary, BOM and fabric stock valuation in a materials ERP; invoices, sale orders and credit notes in Zoho Books; buying and sourcing in a spreadsheet. The people who needed the answers were in none of them, reading the day's numbers in a messaging group. Nobody asked for a new system of record, only for one place where those sources reconcile daily.
One codebase serves all four. Each tenant runs on its own MySQL database, S3 bucket and Redis database number, so records, media and queues never share a namespace.
Connectors for the channel aggregator, factory ERP, materials ERP and Zoho Books, each with its own auth and refresh path, plus Apps Script sheet imports, Drive images and marketplace style stats.
Replenishment splits into B2B and ecom across fabric and finished goods, beside a greige sourcing tracker, planning PO with factory WIP, and an SCM tracker carrying PPM reports.
Daily factory cost against target, fed by an Apps Script webhook and pushed to the messaging group, with a production PnL dashboard carrying marketplace style stats, ads and CM2.
Celery workers on Redis run the ETL into BigQuery, including replenishment pushes and per style LLM analysis through OpenRouter. Around 35 django-crontab jobs schedule the rest; reports leave as Excel and PDF to Slack, messaging groups and email.
Tradeoffs
Every choice closed off something else. Those costs are stated, not hidden.
Instead of: One database with row level filtering on a tenant id. Separate factories and books, and per tenant ETL heavy enough that one should not slow another.
What we acceptedEvery migration runs four times, connection pools multiply, and no cross tenant question survives a JOIN.
Instead of: Webhooks and streaming from each upstream system. Several sources publish on their own batch schedule with no usable event stream, and a re-runnable pull recovers more cheaply than a missed event.
What we acceptedData is only as fresh as its cron window, and roughly 35 jobs need watching, hence the run tracker.
Instead of: Read replicas and heavier indexes on the primary. The operational database carries a large append only history stream, so analytical scans compete with the write path.
What we acceptedA second copy with its own lag, and two places a number could be computed, so definitions pin in the pipeline.
Reusable
Every multi system apparel stack argues with itself eventually. The ownership map underneath:
| System | Owns | Do not ask it for | How the data arrives |
|---|---|---|---|
| Channel aggregator | Channel orders, inventory sync, returns, GRN, putaway | Landed margin, factory cost | Continuous pull, returns restate for weeks |
| Factory ERP | Production output, GRN summary, defects, cost per unit | What actually sold | Daily, after shift close |
| Materials ERP | Item summary, BOM, stock, fabric valuation | Finished goods at the channel | Daily batch |
| Zoho Books | Invoices, sale orders, credit notes, customer master | Physical stock | On document creation, token expires |
| Marketplace direct | Style stats, ads, CM2 inputs | Order truth, cancellation restates it | Reporting lag of days |
| BigQuery warehouse | Reconciled history everyone reports off | Anything live or operational | Whenever the ETL last ran |
The system that owns the event owns the number, and reconciliation belongs in the pipeline, never in each dashboard.
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.
An IP whitelist middleware geolocates the caller, with per profile activity tracking behind it. Records and media stay in the tenant's own database and bucket.
Because isolation is physical rather than a query filter, separating one business is a copy, not an extraction. Marketplace, accounting and messaging credentials stay in the client's accounts.
Nobody watches 35 jobs by eye, so a report status page records every cron run and allows a re-trigger. A failed job shows as a row, not an email nobody received.
Reflection
The style history table should have been append only and partitioned from the start, with a short retention window in MySQL and the long tail in BigQuery. It grew inside the operational database instead, so a schema change is now a scheduling exercise rather than a migration. Two schedulers is one too many: django-crontab and Celery overlap. The per style AI read stays advisory, because we have not earned the right to let it move a number.
Because a shared table with a tenant filter puts every future query one mistake away from exposing another company's costing. Separate databases make isolation an infrastructure property, with per business backup and retention. The cost is real: every migration runs four times, and cross tenant questions need a warehouse.
Because a marketplace sale is not final when placed. Cancellations, returns to origin, customer returns and settlement adjustments all restate it, sometimes weeks later. Pulls upsert on the channel's identifier, so a restatement corrects the row instead of adding one.
Inside the ETL pipeline, not the request path. Celery workers assemble the data for a style, send it through OpenRouter, and store the result where planners see it. It suggests; a person decides what to repeat, discount or drop.
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.
