Putting It Together — Modeling Print in Software (PF360 lens)

Every earlier chapter taught you a piece of the print craft: paper, color, presses, finishing, files, shipping. This chapter is the synthesis. We take all of that physical reality and ask one question a software builder must answer: what does the data model need to look like so the screen tells the truth about the factory?

Before we go further, two plain definitions you'll see throughout:

• Data model — the shape of the information your software stores: which fields exist, what type they are, and how records connect (an order has many line items, a line item has one spec, and so on).
• Spec (short for specification) — the full description of exactly what is being printed: size, paper, colors, finishing, quantity. In print, the spec is the heart of the order.

The core insight: a print job is a recipe, not a product row

Normal e-commerce models a SKU — a Stock Keeping Unit, which is one fixed sellable thing with a known price sitting on a shelf. A t-shirt comes in S/M/L; you pick one and the price is looked up from a table. That model works because the variants are finite and the price already exists.

Print breaks this. A print product is a configured manufacturing spec — the customer assembles a recipe (size × paper × ink-sides × quantity × finishing), and the price, weight, file requirements, and turnaround all change with the recipe. There is no shelf and no pre-known price; the software computes everything from the configuration.

Three specific things make print software hard, and generic Shopify-style models get all three wrong:

1. Price is computed, not looked up. It comes from many interacting attributes, not a single row.
2. There is a mandatory human gate mid-order: proof approval. The order pauses, waits on the customer, and legally cannot proceed without a recorded sign-off.
3. The order produces a physical thing through a multi-stage pipeline that can split (partial shipment) and merge with other customers' orders (gang run). A single "shipped: yes/no" flag is not enough.

Where this category of software lives

Two industry terms you'll meet talking to shops:

• Print MIS / Print ERP — Management Information System (or Enterprise Resource Planning). The back-office software a shop runs: estimating/quoting, order entry, the job ticket (the printable work order that follows a job through the floor), scheduling, inventory of paper and ink, job costing, shipping, invoicing.
• Web-to-print (W2P) — the customer-facing online storefront that lets buyers configure and order, then feeds those orders into the MIS.

The industry's stated ideal is "ecommerce orders become MIS job tickets automatically — zero re-entry, zero errors." A platform like PF360 is essentially W2P plus a light MIS: it must both sell the configurable product and track it through production.

The product spec data model — what print actually needs to capture

The spec must be structured, machine-readable data (the industry literally passes it around as JSON, XML, CSV, or a JDF job ticket — Job Definition Format, the print industry's standard digital work-order file). Here is what every spec carries.

1. Size and dimensions

Capture width, height, and units. Two sizes can matter at once:

• Flat size — the size of the unfolded sheet (a tri-fold brochure is flat 11×8.5").
• Finished size — the size after folding/trimming (that brochure finishes at ~3.67×8.5").

For wide-format (large prints like banners and posters), size is continuous — any width × height — not a picklist. That single fact forces a different pricing engine (square-foot pricing, below). Also store the bleed size = trim size + 0.125" on each edge (defined fully in the file section).

2. Stock / substrate (the paper or material)

Substrate just means the material you print on. Its weight is expressed in three competing systems, and this is a classic data-model trap.

Lock in these conversions and reference equivalents:

Conversion factors to GSM: bond ×3.76, text ×1.48, cover ×2.70. Business cards are commonly 14 pt and 16 pt; the USPS postcard minimum is 7 pt.

Two more stock fields worth modeling for heavier work:

• Grain direction (long grain / short grain) — the orientation of the paper fibers. Folding against the grain on heavy stock cracks it, so the job ticket should allow specifying grain for thick stocks.
• Coating — gloss / matte / uncoated. This affects which inks and finishing options are compatible (foil and some coatings clash).

3. Color / sides — the 4/4 vocabulary (a trust signal)

Printers describe ink coverage as front/back ink counts. The number before the slash is the front; the number after is the back.

• CMYK = the 4 process colors: Cyan, Magenta, Yellow, Black (the "K"). So "4" almost always means full color.
• 4/4 ("four over four") = full color both sides.
• 4/0 = full color front, blank back.
• 4/1 = full color front, single ink (usually black) back.
• 1/1 = black both sides; 1/0 = black front only.

Beyond CMYK there are PMS / Pantone spot colors — exact branded inks mixed to a recipe (a logo red that must be identical every time). Each spot color is an extra ink, an extra plate, and extra cost.

4. Finishing options — priced choices with compatibility rules

Finishing (also called bindery or post-press) is everything done after the ink is on the sheet. These are the high-margin add-ons, and each one is a selectable option that can add cost, production time, and weight, and may be incompatible with certain stocks. The real terms a shop expects:

For multi-page products, binding is the finishing choice that holds pages together:

5. Page count (multi-page products)

Booklets and books need a page-count field, and for saddle stitch it must be a multiple of 4 (each folded sheet = 4 pages). Page count drives the binding choice, the imposition (how pages are arranged on the press sheet — defined below), and the price. Validate it.

Pricing models — where print diverges hard from e-commerce

1. Quantity price breaks (tiered pricing)

This is the default for short-run work. The per-unit price falls as quantity rises because the setup cost (plates, press make-ready, prepress labor) is fixed and gets spread across the run. At low quantity, setup dominates the total; at high quantity, per-piece material cost dominates.

Per-unit price as quantity rises (setup amortized)

$/unit
  |*
  | *
  |   *
  |      *  steep drop in the low-mid hundreds (25 -> 250)
  |         * * *
  |              * * * * * *  curve flattens after ~1000
  +------------------------------------------- quantity
   25   100   250   500   1000   2500   5000

Breaks sit at thresholds the shop sets, e.g. 100 / 250 / 500 / 1000 / 5000. The steepest savings are in the low-to-mid hundreds; after 1000 the curve flattens. Model it as price = setup_fee + (per_unit × qty) with a tier table.

Distinguish two flavors of quantity discount in your engine — they produce different totals, so pick one and be explicit:

2. Square-foot pricing (wide / large format)

Banners, signs, and posters are priced by area: price = width_ft × height_ft × rate_per_sqft. Real-world rates run from about $1.99 to $8.99 per square foot; ~$8/sq ft is a common standard for digitally-printed banners, budget vinyl can drop to $3–$5/sq ft. The material drives the rate (vinyl is dearer than paper or fabric).

Two refinements: rates are often degressive (each successive square foot is cheaper — a built-in volume curve on area), and there is usually a minimum charge or minimum square footage. In PF360 terms, this is a distinct pricing strategy — a formula like area * rate — sitting alongside the per-unit tier tables, not bolted onto them.

3. One-time and per-color charges

Foil and die-cutting need a one-time die charge; offset spot colors need a plate charge; finishing can be billed per-piece or per-job. Model these as charges that are amortized over the run, separate from the per-unit price.

Production status workflow — the lifecycle your model must track

An order isn't a single event; it's a journey through the shop floor. Model it as an explicit, ordered state machine. Here is the canonical path, with a few new terms defined inline:

Order received
   |
   v
Prepress  (preflight + imposition)
   |
   v
Proof  ---->  PROOF APPROVAL GATE  <----+
   |             |  requests changes    |
   |             +----------------------+  (revise, re-proof)
   |  approves
   v
Approved / scheduled
   |
   v
Printing (on press: make-ready + run + QC)
   |
   v
Finishing / bindery (cut, fold, laminate, bind)
   |
   v
Packaging  -->  Shipped  -->  Delivered

side states: On hold / awaiting files / awaiting payment /
             reprint / cancelled

Modeling rules that matter:

• Two label sets. Show customers plain language ("Proof ready", "In production", "Shipped"), keep internal codes for the floor. Never surface "PREPRESS_QC_HOLD" to a buyer.
• The turnaround clock starts at proof approval, not at order placement (more below).
• Audit every transition — who changed it, from what to what, and when. Status changes are business-critical for support and disputes.

The proof approval gate deserves first-class treatment

This is the one place an order legally and practically pauses on the customer. It must be a versioned, audit-logged gate: store every proof version, who approved it, and the exact timestamp. The approval timestamp is what anchors the production SLA clock.

File / preflight requirements — the order isn't real without a valid file

Preflight is the pre-print validation of the customer's file (like a pilot's pre-flight checklist). Four core checks every print PDF must clear:

Quick definitions: DPI = dots per inch, a measure of image detail. Bleed = artwork extended past the trim so no white edge shows after cutting. Trim = the final cut size. Crop marks = guides showing where to cut. There are also two file standards to know:

Shops run preflight automatically and reject non-compliant files with a report; production cannot start until the file is corrected and re-uploaded.

Turnaround / SLA — model time honestly with two clocks

SLA = Service Level Agreement, the promised timing. The critical rule: production turnaround and shipping transit are two separate clocks — never merge them. If you blend them, customers blame the shop for a carrier's delay.

• Production turnaround = proof approval → ready to ship, counted in business days (no weekends/holidays), starting the day after approval. Typical standard is 3–5 business days; rush can be 24 hours, often with a cutoff ("approve before noon or it slips a day").
• Shipping transit = the carrier's separate clock once the parcel leaves.

Model implication: store production_days and rush options per product; compute the estimated ship/delivery date from the approval timestamp + a business-day calendar + the chosen shipping method; and display the two legs separately.

Weight & shipping — derive the physical numbers from the spec

Each finished piece has a weight. Total parcel weight = (per-piece weight × quantity) + packaging. Per-piece weight comes from the stock (GSM × sheet area) plus any weight-adding finishing (lamination, heavier covers). The packed parcel's dimensions drive dimensional (DIM) weight — carriers charge on size as well as actual weight for bulky-but-light parcels.

Partial fulfillment — the order can split

A print order often ships in parts: a multi-product order where one item finishes first, a "blind drop ship" sending pieces to several addresses, or staged delivery. Partial shipment means the order is delivered in fragments as items become ready, with the rest following later (and shipping may be charged per shipment).

Gang run / batching — orders merge at production

A gang run places multiple separate jobs on one shared press sheet so they split the setup, plate, and press cost and waste less paper; the sheet is cut apart after printing. (A combination run is the same idea for related variants.)

The hard constraint: every ganged job must share the same stock and ink/color spec, and it works on sheet-fed CMYK presses. The downsides you must be able to model and communicate:

• Color accuracy is harder — roughly 10% color variance is "standard" in gang runs. Sensitive colors (orange, purple, brown, neutral gray, lime green) drift most.
• "Ghosting" — a neighbor's heavy solid ink area can faintly affect your piece.
• Reprints cost more — rerunning your piece reproduces the neighbors too.
• Unsuitable for special stocks, special effects, or tight brand-color jobs.

Model implication: a batch / gang entity that groups eligible jobs by shared stock + color + size. Jobs flow individually through prepress and proof, then merge at the printing stage, then split again for finishing and shipping.

Three concrete examples (the model end-to-end)

A. Business cards — short-run, gang-run candidate

• Spec: 3.5×2", 16 pt gloss-coated cover (~350 GSM), 4/4; options: matte lamination + rounded corners + spot UV.
• Pricing: quantity tiers (250 / 500 / 1000 / 2500), setup amortized; lamination per-piece, rounded-corner die one-time.
• Production: prepress → proof → approval → gang run with other 16 pt cards → cut → laminate → ship in 3–5 business days.
• File: 3.5×2" + 0.125" bleed, CMYK, 300 DPI, fonts embedded.

B. Vinyl banner — wide format, square-foot pricing, no gang

• Spec: 36"×80" (≈20 sq ft), 13 oz scrim vinyl, 4/0; finishing: hemmed edges + grommets every 2 ft.
• Pricing: 20 sq ft × ~$8 ≈ $160 + hem/grommet add-ons; degressive rate on larger sizes; minimum charge applies.
• Production: large-format printer (no plates); finishing = weld/hem + grommets; high weight → real freight cost.
• File: artwork scaled (often 1:1 or 1:10), CMYK; lower DPI acceptable at viewing distance.

C. Saddle-stitch booklet — multi-page, binding, partial fulfillment

• Spec: 8.5×11", 28 pages (multiple of 4), 100 lb gloss text interior (148 GSM) + 100 lb gloss cover (270 GSM), 4/4 throughout, saddle stitch, aqueous coat on cover.
• Pricing: per-page + cover + binding + quantity tiers; page count drives imposition into signatures.
• Production: prepress imposes signatures → proof (page sequence checked) → print → fold → collate → stitch → trim → ship. If ordered alongside other items, booklets may ship separately when bindery finishes → partial fulfillment.

Common mistakes (the software-builder checklist)

• Modeling print as fixed-variant SKUs instead of a configurable spec — can't represent size×stock×sides×finishing×qty.
• Treating "sides" as a boolean instead of the 4/4 vocabulary (full color vs spot, front/back independent).
• Looking up price instead of computing it; ignoring setup-fee amortization → wrong totals at low quantity.
• One pricing strategy for everything — wide format needs square-foot, cards need quantity tiers.
• No proof-approval gate, or no version/approver audit trail → "I never approved that" disputes.
• Starting the turnaround clock at order placement, and merging production + shipping time.
• Order-level single shipment (no 1:N) → can't do partial / backorder / multi-address.
• Not validating finishing/stock compatibility → impossible jobs accepted.
• Storing only ambiguous "lb" weight instead of canonical GSM → wrong stock and wrong shipping.
• No preflight gate, or surfacing raw rejection codes instead of plain "Your file is low-resolution; please upload 300 DPI."
• Not snapshotting spec/weight/finishing onto the order → later edits corrupt historical orders (the "silent-lie" class).
• Tangling non-priced custom/metadata fields with pricing-bearing options — keep them separate.

Vocabulary cheat-list — talk to a printer and earn trust

Use these terms correctly and a real shop will treat you as someone who understands the craft.

How to talk to a printer

When you call a shop to validate your model or get a quote, lead with the spec in their language, not yours. Don't say "I need a small double-sided card thing in heavy paper." Say: "3.5 by 2, 16-point gloss cover, 4-over-4, matte lamination both sides, rounded corners, 500 pieces — what's your standard turnaround from proof approval, and do you gang these?" That one sentence tells them you know size, caliper, ink coverage, finishing, quantity, the SLA clock, and gang runs. Then ask the questions that fill gaps in your data model: "How do you handle a file that fails preflight?", "Do you charge shipping per shipment on partial deliveries?", "What's your color variance tolerance on gang runs?"