Apparel ERP software
Apparel ERP software, from people who built one and run it daily.
This page is not a product pitch. It is what we know about ERP for the apparel industry after building one for our own eight-figure decoration business and using it every day since.
Most ERP was written for a warehouse that picks finished goods off a rack. An apparel business with decoration in-house does the opposite: the order lands, and then the goods get made. Nearly every gap between apparel operators and their software traces back to that one difference. What follows is the shape of the gap, an honest way to decide whether to buy or build, and what we would tell you if you rang up tomorrow.
The gap
What apparel ERP has to handle that generic ERP does not.
Seven assumptions are baked into general-purpose ERP. Every one of them is wrong on a decoration floor, and each one produces the same symptom: a spreadsheet appears next to the system, and within a year the spreadsheet is the real system.
| Generic ERP assumes | A decoration floor actually does |
|---|---|
| Goods exist, then the order arrives | The order arrives, then the goods get made |
| Decoration is a variant attribute | Decoration method decides the machine, the queue, the consumables and the reject rate |
| One job belongs to one order | One gang sheet carries items from twenty orders, and one order spans several sheets |
| Stock can never go below zero | Stock goes negative on purpose, and an append-only ledger records why |
| Warehouses are interchangeable stock locations | Sites differ by capability — DTG here, embroidery there, licensed blanks somewhere else |
| A misprint is a return | A misprint is a routine production event, a consumed blank and a re-queued job |
| Artwork is an attachment on the order | Artwork is work in progress with its own prep queue and its own failure modes |
Decoration method is a routing decision
A black hoodie printed DTG, the same hoodie printed DTF, and the same hoodie embroidered are three different production paths. They use different machines, different consumables, different cure or hoop times, and they fail differently. Generic ERP records the method as a line-item attribute. It needs to be the field that decides which queue the job enters and which other jobs it is batched with, because that decision is most of your cost per unit.
Artwork is work in progress
Every order carries a file, and the file is not ready. It has to be checked for resolution, colour profile, transparency and placement, scaled per garment size, and stored so that a reprint in eight months produces the same result as the original. That is a production step with a queue, a person and a failure rate. Generic ERP has no concept of an input that must be prepared before the item can be made, so artwork prep never appears as a cost — it appears as a designer who is always busy.
Gang sheets break one job per order
DTF economics depend on ganging: many designs from many orders imposed onto one roll so film and ink are not wasted on white space. That means one physical production artefact maps to items from dozens of orders, and a single order can be spread across several sheets printed on different days. An ERP that assumes a job belongs to an order cannot represent that, so the imposition lives in a separate tool and the link between the sheet and the orders on it lives in someone’s head.
Stock has to be allowed to go negative
Made-to-order consumes blanks after the sale. If the system blocks the sale the moment on-hand hits zero, a receiving delay turns into lost revenue. If it quietly allows the sale without recording it, you lose the audit trail and the count never reconciles again. What you want is negative stock, on purpose, with an append-only ledger of every movement, so six months later you can read back exactly what happened rather than arguing about it.
Multi-warehouse means multi-capability
Two production sites are rarely interchangeable. One has the DTG line, one has DTF and embroidery, one holds the licensed blanks that cannot legally ship from anywhere else. Generic multi-location logic optimises for distance and available stock, then routes a job to a site that cannot decorate it. Routing has to consider what can be made where before it considers what is nearest.
Rework is normal, not exceptional
At volume, misprints are a rate, not an incident. The system has to consume another blank, re-queue the job, leave the customer’s order intact, and record the reason — so you can see rework broken down by press, operator, garment and design. Handle it as a return and you have corrupted both your inventory and your sales data to describe something that never left the building.
Decision framework
Buy or build, honestly.
First, price the thing you already have
Count the hours per week your team spends moving data between systems, rebuilding a stock position, chasing an order that stalled between two tools, or redoing artwork that was already done. Multiply by a loaded hourly rate and annualise it. That number is what both options get compared to, and until you have it every conversation about software is a conversation about taste. Almost nobody does this, which is why so many implementations cannot say afterwards whether anything improved.
Buy when your process is ordinary
If your decoration mix, routing and fulfilment look broadly like everyone else’s, somebody has already built the system and amortised it across hundreds of shops. Print MIS and decorator platforms exist, they are not bad, and they will be cheaper than anything bespoke. Pay for one. The buy option deserves a serious trial before you write a line of code.
Buy when what is missing is a feature, not a shape
If an off-the-shelf product does eighty per cent of the job and the missing twenty per cent is a report, a webhook or an integration, buy it and build the twenty per cent around it. That is a far smaller commitment than a platform, and it keeps the vendor maintaining the boring parts. Build only when the missing part is structural — when the product cannot represent a gang sheet, or cannot let stock go negative, and no amount of configuration will change that.
Build when the process is the advantage
If the way you route, batch and gang work is the reason your cost per unit beats the shop down the road, an off-the-shelf system will quietly average you back toward the market — because it encodes what most shops do. That is the strongest case for building, and it is much rarer than people think. Be honest about whether your process is genuinely different or just familiar.
Do neither yet if you cannot state a baseline
If you cannot say how many hours a week reconciliation costs, or what your rework rate is, or how long an order sits between paid and printed, then buying and building are both gambles you will not be able to grade. Measure first. It is the cheapest step available and it is the one almost everybody skips, which is a large part of why so many software projects end with nobody able to prove anything changed.
Both options have a failure mode
Buying fails when the workarounds pile up until the spreadsheets come back, and you are paying a licence fee to keep them company. Building fails when the system becomes unmaintained — the developer moves on and nobody left can safely change it. Both are real, and anyone who tells you only the other one is real is selling. The second is mitigated by owning the code and the data outright, and by building on infrastructure a competent developer will recognise — not by trusting the people who built it to stay interested.
What we built
One system, in one apparel business.
Threadheads is a Shopify apparel business doing eight figures a year with in-house DTG and DTF decoration across more than one production site. Ace owns it. The system described below runs its production floor, and has since it was built.
Orders sync from Shopify in real time. The floor works from a print queue grouped by garment, decoration method and run window rather than a list of checkout receipts. Scan-to-print and scan-to-pack replaced the spreadsheet as the record of what has actually been printed and packed. Stock runs on a negative model with an append-only audit trail, so a made-to-order sale is never blocked and never untraceable. Fulfilment across sites sits under one view, and purchase orders are tracked from supplier through to arrival.
We are not selling you that system. It is not a product, there is no self-serve signup, and it is shaped around one operation’s decisions. It is here because it is the reason we can describe the problem accurately, and because you should know what somebody means when they say they have built one.
The Threadheads case study has the figures we can source, the ones we are withholding, and why.
Scope
When custom is the right call.
Custom is right when the shape of the work does not fit anything on the market, when the integration surface between your systems is where the value actually sits, or when the process you would have to abandon to fit a product is the process that makes you money. It is also right when you have already bought twice, worked around it twice, and can name exactly what broke both times.
It is the wrong call when the real problem is that nobody owns the data, when the process is undocumented and would simply be hard-coded in its current confused state, or when the business is about to change shape. Building a system around a process you are midway through changing is an expensive way to make the change harder.
When we do build, it is quoted as a fixed number before we start, and the code and the data are yours in the agreement rather than as a favour on the way out. You can get development cheaper than us — genuinely cheap development exists now and for some jobs you should use it. What is harder to buy at that price is somebody deciding what to build who has run the operation you are describing. The build is the easy half; getting the spec wrong is what costs real money.
Questions
The ones operators actually ask.
- What is apparel ERP software?
- ERP for the apparel industry is the system that holds orders, production, inventory, purchasing and fulfilment in one place for a business that makes or decorates garments. The distinction that matters is whether it models production. A system that only tracks finished goods in and out is inventory software; a system that knows a garment has to be decorated before it can ship, and can route and batch that work, is an apparel ERP.
- Isn't Shopify enough on its own?
- Shopify is a good system of record for orders, customers and catalogue, and a poor one for production. It has no model of a print queue, a gang sheet, an artwork prep step or a reject and reprint. Most apparel operators run Shopify plus something for production. The question is whether that something is a spreadsheet, an off-the-shelf product, or a build.
- Can I use a generic ERP like NetSuite, Odoo or Cin7?
- You can, and plenty of apparel businesses do. Expect to spend the saving on configuration and on workarounds where the decoration model does not fit — usually gang sheets, artwork prep and negative stock. The honest test is to write down the five things your floor does that the demo did not show, and ask the vendor to demonstrate all five on your data before you sign.
- What does apparel ERP software cost?
- Off-the-shelf products publish their own pricing, and the number worth comparing it to is not the licence fee but the cost of the workarounds it leaves behind. Custom work from us is quoted as a fixed number before we start, once the scope is known. We do not publish a price grid for it here because scope decides the number and there is no useful average.
- How long does an implementation take?
- It depends on how much of your process is already written down. What we would insist on either way is a parallel run: the old process and the new one operating side by side for a period, so the floor can fall back without drama. Cutovers that skip the parallel run are the ones that end up in a war room.
- Do you sell your apparel ERP as a product?
- No. The system described on this page runs one business — ours. We build custom systems for other operators, and where an off-the-shelf product would do the job we say so and point you at the category. That is a worse business for us and a better answer for you.
Next step
Tell us what your floor does that the software cannot.
Thirty minutes, no deck. If the answer is that you should buy something off the shelf, that is what we will tell you — it is a faster call for both of us than the alternative.
Bring your numbers. Ace takes these calls.