← All work

Our Product · SaaS / Apparel Decoration

POOF

Proof-to-approval for custom apparel, with evidence

poofcreator.com →

RFC 3161

trusted timestamping

2

live wholesaler catalogs

0

accounts needed to approve

Hash-chained

append-only ledger

The Problem

In apparel decoration, the expensive dispute is always the same one: the customer says they never approved that. A screenshot of an email is not evidence, and an approval flag in a vendor's own database is not evidence either, because the vendor controls the database. Shops eat the cost of reprints they did not cause, because the record of what was agreed is held entirely by one of the two parties to the argument.

The Approach

  1. 1

    Capture what was actually agreed, not that agreement happened. At the moment of approval the system snapshots the full proof state: garment and colorway by code and name, every print zone with coordinates, every artwork file with its print dimensions and colors, every placement, and the customer-visible comment thread.

  2. 2

    Serialize it so the hash is reproducible. The snapshot is canonical JSON with fixed property ordering, wrapped in an envelope carrying the approval, proof, and organization identifiers plus the approver's identity as taken from the approval link rather than from user input.

  3. 3

    Get the timestamp from someone with no stake in the outcome. The envelope hash is submitted to an external RFC 3161 Time Stamping Authority, and the returned token plus the TSA certificate chain at time of issue are both retained.

  4. 4

    Make verification possible without POOF. The evidence package ships with the raw timestamp token, the certificate chain, the canonical bytes, and a verification walkthrough using stock OpenSSL commands, so an opposing party can check the claim with tools they already trust and no cooperation from us.

  5. 5

    Remove friction from the customer side entirely. Approval happens on any device from a single link, with no account to create, because an approval flow that requires a signup is an approval flow that does not get completed.

What It Does

  • Proof building from live SanMar and S&S Activewear catalog data: real garments, real colorways, real codes
  • Multi-zone proofs with artwork placement, print dimensions, and per-zone color specification
  • Single-link customer approval on any device, no account required
  • RFC 3161 trusted timestamping of every approval, with the TSA certificate chain captured at issue
  • Hash-chained, append-only approval ledger: records are added, never quietly edited
  • Court-ready evidence package: narrative summary PDF, machine-readable manifest, canonical envelope, proof snapshot, timestamp tokens, and an OpenSSL verification guide
  • Independent re-verification report generated by the platform against its own records
  • Customer comment threads captured into the approval record, so the conversation is part of what was signed off
  • Press-ready, color-separated PDF output for the shop floor

Engineering Decisions

The choices worth defending in a technical conversation, and why they were made.

Canonical serialization, because hashes are unforgiving

Two JSON documents with identical content and different key ordering hash differently, which would make every stored proof unverifiable. Property order is fixed at serialization time so the bytes that were hashed can be regenerated exactly, years later.

Third-party time, not our own clock

A timestamp issued by the party who benefits from it proves nothing. Going to an external RFC 3161 Time Stamping Authority is what moves the claim from 'our system says so' to something an outside expert can verify, and it is why the certificate chain is captured at issue rather than fetched later.

Colorway is part of the agreement

The same artwork on a different garment color is a different thing to sign off on, and it is a common source of dispute. Garment color is captured in the snapshot by both code and name, deliberately.

Approver identity from the link, not the form

The approving email address comes from the approval link rather than from a field the approver types into. An identity the subject can edit is not an identity worth timestamping.

Honest about what it proves

The product documentation states what the evidence establishes and what it does not. A cryptographic claim oversold is a cryptographic claim that fails in the one conversation it was built for.

The Stack

Cryptographic integrity

RFC 3161 trusted timestampingSHA-256 canonical hashingHash-chained ledgerAppend-only storageOpenSSL-verifiable output

Platform

.NET 10Next.js 16React 19Tailwind 4SQL Server

Integrations

SanMar catalogS&S Activewear catalogMSAL admin auth

Output

Color-separated press-ready PDFsEvidence package generation

Want something like this built?

Let's talk about what you're building and how we can help.