StitchTrack
Custom embroidery management software
Orders, designs, machines and job-work billing, tracked by stitch.
For embroidery units running multi-head machines on job work, where a design's stitch count decides the price, machines are booked by head-hours, and the same party sends fabric one week and takes finished goods the next. Built around job cards and machine capacity rather than a generic manufacturing model.
Screens
What it looks like
4 screens from the working demo — the same data you will see if you open it.
The problem
Why this gets built
Job-work embroidery is billed per thousand stitches across multiple machines and heads. If production is not captured accurately at the machine, the invoice is a guess and the margin is unknowable.
Who it is for
Fit
Embroidery job-work units running multiple machines for multiple parties.
Capabilities
What the system does.
Order tracking
Party, design, quantity, rate and delivery date, with status visible from enquiry to dispatch.
Design library
Design codes with stitch counts, colour sequences and the machines they run on.
Machine scheduling
Multi-head machines with run allocation, so capacity is planned rather than discovered.
Production capture
Stitches and pieces recorded per run and per shift, feeding billing directly.
Thread & material stock
Colour-wise thread inventory consumed against production runs.
Job-work billing
Rates per thousand stitches computed from actual production, not estimates.
See it running
StitchTrack is a clickable demo — open the modules, browse the tables, see how the screens fit together.
Buying decision
Why off-the-shelf falls short here.
An embroidery unit is not a factory that makes its own goods. Most of the fabric on the floor belongs to someone else, arriving on a challan and leaving on a challan, with only the work billed. Standard manufacturing software wants a bill of materials and a finished-goods stock, and has nowhere to put material it does not own.
Capacity is also the wrong shape. The constraint is not people or machines but heads and stitch-hours: a twelve-head machine running a 40,000-stitch design has a throughput you can calculate exactly, and scheduling that is the difference between a promised delivery date and a guessed one. Generic job-shop scheduling has no concept of it.
A custom build treats the job card as the centre: party, design, stitch count, heads allotted, thread consumed, pieces in and out. Costing and billing both fall out of it, and so does an honest delivery date.
Comparison
Packaged product vs a custom build.
The differences that decide it, for this sector specifically.
| Aspect | Packaged product | Custom build |
|---|---|---|
| Material ownership | All stock is yours | Party-owned fabric tracked in and out on challan, never mixed into your own stock or valuation |
| Costing basis | Per unit produced | Per stitch, per head-hour or per piece, whichever that party is billed on |
| Scheduling | By machine or by worker | By machine head and stitch count, so a delivery date is computed rather than promised |
| Designs | A product code | A design master with stitch count, colour sequence and thread estimate, reused across parties |
| Thread | A consumable with a monthly total | Estimated per design and reconciled against actual, so overuse is visible per job |
| Rejections | A scrap percentage | Recorded per job and per machine, with rework tracked as its own pass |
Integrations
What it connects to.
A system that cannot reach the tools already in use becomes another island. These are the connections this sector normally needs.
Accounting
Job-work invoices and purchase entries posted to Tally or Zoho Books with the correct GST treatment for job work.
Machine data
Stitch counts and run time read from the machines where the controller allows it, rather than written on a slip.
Design files
DST and emb files stored against the design master so the floor loads the right version.
Delivery challans
Inward and outward challans for party-owned goods, with e-way bills where the value requires one.
Messaging
Job status and delivery-ready alerts to the party, without a phone call.
How it runs
From first conversation to cutover.
Indicative for a build of this shape. The parallel run is not optional — nothing is retired until the numbers agree.
- 1 week
Discovery
We take your rate card, a set of real job cards and your machine list with head counts.
- 3-6 weeks
Core build
Job cards, design master and machine scheduling first, because billing and costing both derive from them.
- 2 weeks
Floor pilot
One machine bank runs on it while the slips continue, until the stitch and thread figures agree.
- 1-2 weeks
Rollout
All machines, party ledgers and job-work billing switched on.
After rollout
What changes day to day.
- A delivery date is computed from stitch count and available head-hours instead of estimated by the person who answers the phone.
- Party-owned fabric stays visibly separate from your own, which is what makes the job-work GST position defensible.
- Thread overuse shows up against the job and machine that caused it, while the operator can still remember the run.
- Billing matches the work done because both come from the same job card.
Described qualitatively on purpose. We do not publish percentage improvements we cannot attribute to a named client with their agreement.
Questions
Common questions.
Can it bill job work by stitch count?
Yes. Production is captured per run and per machine, and job-work rates per thousand stitches are applied to actual output rather than estimates.
Does it track multi-head machines?
Yes. Machines are configured with their head count and runs are allocated against them, so capacity is planned rather than discovered.
How is thread stock handled?
Thread is tracked colour-wise and consumed against production runs, so a shortage appears before a run stops.