Your artwork, your customer list, your invoice history.

Signing in from a new device sends a six-digit code to the address on the account. The code is stored hashed, never in plain text, and it is useless once used.

Confirm a device once and it stops asking for a code on that browser. The token behind it is random, held server-side against one user, and expires on its own.

Failed sign-in attempts are counted against the identifier being tried, not the whole system, so someone hammering one account cannot lock everyone else out and cannot keep guessing either.

Stored with bcrypt. When the standard moves on, an older hash is re-hashed the next time that person signs in successfully — nobody has to be told to reset anything.

A reset link carries a token that is stored hashed and consumed the moment it sets a new password. Sending yourself a second link invalidates the first.

The session identifier is regenerated at sign-in and again whenever an account's privileges change, so a session captured before a change cannot be replayed after one.

Every listing is scoped to the company asking for it in the SQL itself. A page is not fetching everything and then hiding the rows you should not see — the rows never leave the database.

A login has a scope (shared team, named staff, or a client), a role within it, and separate switches for the print and social sides of the platform. A print-only staffer does not get a social page rendered and gets refused on a direct call to a social endpoint.

Staff scoped to particular clients see those clients and nothing else. If someone has no assignments recorded, that means no access — not, as the easier implementation would have it, access to everything.

Actions are written to an activity log, with owner-only and internal-only entries kept separate so a client login cannot read your staff's trail or your commercial notes.

Your customer approving a proof never creates a login. That is deliberate: an account we do not create is a password we cannot leak, and it removes the single most common reason a proof sits unapproved for a week.

Each approval link carries a token of sixteen random bytes. There is no sequence to walk and no list to enumerate — a wrong token matches nothing at all.

The endpoint behind an approval link returns only the fields needed to render the one proof the token names. It never returns a list, another customer's job, or anything about your shop beyond the branding on the page.

The approval page, the client portal, the sign-in page and the proof endpoint all tell crawlers not to index them, and they are left crawlable so that instruction is actually read rather than blocked at the door.

Every folder that receives an upload carries a rule denying execution of anything script-shaped. The rule is re-written on every single request, not just at install — so a folder that loses it gets it straight back rather than sitting exposed until someone notices.

The five prepress tools on this site have no upload endpoint in the code at all. Your artwork is read by your own browser and discarded when the tab closes. That is a fact about how they are built, not a promise about how we behave.

When you connect a Facebook or Instagram account, the access token is encrypted before it is stored, each with its own initialisation vector.

The database is pinned to UTC and every time is converted in the viewer's own browser. An approval timestamped at sign-off reads correctly whether it is being checked from Islamabad, Dubai or Manchester — which matters when the timestamp is the evidence.