One label service instead of a label program per label

The situation. Labels were being produced from several unrelated places — contract bins, order lines, invoice lines, purchase-order lines. Each had grown its own path to a printer. Adding a label type meant writing another program, and the layouts drifted apart because nothing held them to a shared definition.

What was built. A single label service with the sources defined as data rather than as code. Configuration tables in the ERP database describe each label source: the query that produces the rows, the fields it exposes, and the template it maps into. A .NET API serves those sources, an admin panel maintains them, and the user-facing side becomes one interface that changes behaviour by configuration.

Output is native printer command language for industrial label printers, rather than a rendered image. For a floor printer this matters — it prints faster, positions predictably at the label edges, and does not degrade when the printer is asked to scale.

The design decision worth stealing. Adding a label type should be a configuration change, not a deployment. Once the source is a row in a table — a query, a field list, a template — the fifth label type costs a fraction of the first, and the layouts stay consistent because they share one rendering path. Most label sprawl is not a printing problem. It is the absence of a place to define a label source.

Worth measuring if you run this

• Elapsed time to add a new label type, before and after.
• Reprints caused by layout or alignment faults, per week.
• Number of distinct programs that can talk to a printer — the number you are trying to drive to one.