All work

fullstack

Axiom InstaProof

Turning print proof approval into a self-serve browser workflow

Senior Software Developer — feature lead2024 – 2025

The problem

Commercial print work fails expensively. If artwork is misaligned against the bleed or trim area, the error is only discovered after the job is on press — so proofs were being exchanged over email, marked up by hand, and re-sent. Every round trip added a day, and nothing about the process was auditable.

What I built

A canvas-based proofing editor that puts the alignment decision in the customer’s hands, with guardrails that make an invalid proof hard to submit.

  • A zoomable, pannable canvas (0.6×–5×) with magnetic snapping at two thresholds, so artwork locks cleanly to guides instead of landing a pixel off.
  • Two explicit alignment modes — Bleed Line (extend artwork past the trim boundary) and Cut Line (align to the final trim area) — because conflating them is the single most common cause of a reprint.
  • A layer rail and alignment controls for multi-image proofs, with per-image processing/loaded/error states so a slow upload never looks like a broken one.
  • A four-state approval flow — pending, approved, rejected, request adjustment — with dedicated modals for rejection uploads and adjustment requests.
  • Server-side proof batches and shareable proof links, so a proof can be reviewed by someone without an account.

Handling real print files

Print artwork is not web artwork. Files arrive as multi-page PDFs and CMYK TIFFs at sizes that will not decode in a browser tab unaltered. The pipeline normalises uploads with sharp and UTIF, renders PDF pages with react-pdf, and composes approved output with pdf-lib, with originals kept in S3 and only derived previews served to the canvas.

Measuring it

Every proof download is recorded as its own event rather than a counter, which makes the data queryable after the fact. The model carries compound indexes for the access patterns that mattered — by batch and recency, by user over time — and range queries are timezone-aware and validated, so a customer in one region and an operator in another see consistent daily buckets.

More work