What actually drives the cost is scope. A single workflow, say routing embroidery proofs for approval and logging the response, is a narrower build: one or two integrations, a defined set of steps, fewer edge cases. A system that also chases reorders, collects size runs from client staff across departments, and answers quote requests is a bigger build: more integrations (order system, email, whatever spreadsheet or form people currently use for sizes), more decision points, and more exceptions to handle. Scope is the first thing that sets cost, before anything else about the system does.
The second driver is build-only versus build-and-operate. Build-only is a one-time engineering cost: we map the workflow, build it, connect it to your tools, and hand it over. Build-and-operate adds ongoing work: we keep the system running, watch for failures, and handle the exceptions that come up over time, so it sits closer to retaining a small team than buying a piece of software. That ongoing piece is why we don't publish a price list. How much operating work a system needs depends on how much of the process it ends up owning, and that's specific to each business.
Some of this work will always need a person. A client disputing a size run, or an embroidery revision that falls outside what was approved, should land on someone's desk, not get pushed through automatically. A system that's honest about its limits says so upfront rather than pretending to own the whole process. The way to judge whether this is worth it: look at how much staff time goes into chasing reorders, forwarding proof approvals back and forth, collecting sizes from client contacts, and answering the same quote questions every week. If that's a real, recurring drain, a short conversation about the specific work is the fastest way to find out what it would take and what it would cost.