Customs paperwork that prints exactly right

The problem

Regulated paperwork has a requirement most software quietly fails: the thing that comes out of the printer has to match the official form. Not approximately. The boxes have to land where the inspector expects them, or the filing can be rejected and the sender makes a second trip.

The people filing these forms are mostly filing the same form. A forwarder lodging declarations week after week re-enters the same consignor details, the same addresses, the same reference formats, by hand, every time. It is slow, and worse, it is slow in a way that invites transcription errors into a document that has legal weight.

The obvious digital fix makes it worse. Most form-filling tools take a scanned image of the official form and float text boxes on top. It looks fine on screen. Printed, the scan is soft, the alignment drifts with the printer’s margins, and the output looks like a photocopy of a photocopy — which is exactly the impression you do not want to give a customs official.

What we built

The form is rebuilt, not overlaid. Each form is reconstructed in real HTML and CSS, dimensioned in millimetres against A4. There is no underlying image. The print is sharp because it is genuinely typeset, and because the layout is declared in millimetres rather than pixels, it does not drift with screen scaling the way an image overlay does.

Records persist and reopen. A filing is saved. Next week’s version of the same declaration is opened, amended and reprinted rather than retyped. The second filing costs almost nothing, which is the entire economic argument for the product.

Printing uses the browser, deliberately. Output goes through the browser’s own print dialog — which also gives Save as PDF for free — with a print stylesheet that strips every piece of application chrome and the on-screen field tint, so only the form sheet reaches paper. No print server, no PDF generation service, no extra failure mode between the user and the document.

New forms are configuration. A generic renderer turns a form definition into a sheet, with a field-detection engine to assist in mapping a new document. Adding the next form is a data exercise rather than a development project — the difference between a product and a bespoke build.

Each user sees only their own filings. Records are isolated by row-level security in Postgres, so the boundary is enforced by the database rather than by the interface asking nicely.

Why it was built this way

Millimetres, not pixels. Choosing physical units throughout is the decision the whole product rests on. Pixel-based layout is at the mercy of browser scaling and printer margins; millimetre-based layout against a declared A4 page produces the same sheet every time. This is determinism applied to paper.

The client key is public, and that is correct. The browser holds only the Supabase anon key; row-level security is what protects the data. The privileged service key never reaches the client. That distinction is worth stating plainly because getting it backwards is one of the most common ways these applications leak an entire table.

It degrades honestly. If configuration is missing, the app shows a “connect your database” screen rather than crashing — a small thing that makes the product survivable in the hands of a non-technical user.

Static assets on the edge. The whole application ships as static assets on Cloudflare Workers. There is no server to maintain, and the running cost is close to zero — which matters for a tool whose users file a handful of documents a week, not a thousand.

The result

A filing that took fifteen minutes of careful typing is reopened and reprinted in seconds, and the sheet that comes out matches the official form rather than resembling it.

Form Pilot is live in production and is the pilot application for our CI and deployment standard — the first system moved onto the new build-and-release pipeline, chosen because it is small enough to prove the pipeline and real enough that proving it means something.