Shop management for decorators

What Platyn is

Platyn is a multi-tenant SaaS for custom apparel decorators — screen printers, embroiderers, and the shops that do both. It covers the path a job actually takes through one of these businesses:

a company calls → someone quotes them against a live blank catalog → art gets drawn, proofed and approved → the job goes to press.

Each shop is a tenant. Tenants share nothing except the blank goods catalog, which is deliberately global: PC61 is the same Port & Company tee whether you are quoting it in Tulsa or Tampa. What differs per shop is the negotiated cost on it, and that is the only part of the catalog that is tenant-scoped.

Who these docs are for

This is engineering documentation, not a user manual. It is the reference for how the system is built and, more importantly, why it is built that way — the decision records carry the reasoning that the code cannot.

The domains

Platyn is a modular monolith. Each domain below is a Rust crate with its own tables, its own invariants, and a narrow surface that the others call through.

Auth & identity Tenants, users, memberships, roles, opaque sessions. One human, many shops.

Companies The buying organization — the school district, the brewery, the agency — and its addresses.

Customers The people at those companies. The one who approves the proof is rarely the one who pays.

Deals Quote through order through production. One record, fifteen statuses, relational size runs.

Catalog Global vendor blanks: styles, colors, canonical sizes, variants, prices, inventory.

Design & artwork Designs, immutable versions, S3 assets, imprints, and token-scoped customer approval.

The dashboard

The dashboard is not its own domain — it is a read-only projection across the others. Open jobs by stage, art waiting on approval, deals with no activity in a week, catalog syncs that failed overnight. It queries the same tenant-scoped tables everything else does, under the same row-level security.

The shape of the system

SvelteKit on Bun

The only internet-facing process. Renders HTML, owns the session cookie, proxies to the API. It never opens a Postgres connection.

Rust API on Axum

All business logic, all data access, all authorization. Not internet-facing. Returns JSON and nothing else — never HTML, never a Set-Cookie.

Postgres 17

Two schemas. app.* is tenant data under forced RLS, self-checked by app.rls_audit(). catalog.* is global and has no tenant_id column anywhere in it. Also the job queue.

Valkey

Cache only. Configured with no persistence on purpose, so nothing can grow to depend on it surviving a restart.

Where to go next

System overview Service topology, the request path, and what each process is allowed to do.

Decision records Nine ADRs covering tenancy, sessions, the job queue, and why there is no Kubernetes.

Local setup From clone to a running stack: web :3000, api :8080, docs :4321.

Testing What belongs in a unit test, a #[sqlx::test], a oneshot contract test, and Playwright.