The clientnever signs in.
Give a client one place to check what is done, what happens next and what needs their input.
FOR STUDIOS KEEPING CLIENTS INFORMED
An independent product. My role: design, development and deployment.
View the mvp / product build package · from $7,500 →- PRODUCT
- Sightline
- ROLE
- Design, build & launch
- AUTH
- Magic link, no passwords
- STACK
- Next.js 16 · Prisma
- DATA
- Postgres · Neon

A project update should be easy to find.
A client wants to know three things: is it moving, what happens next, and is it waiting on them. Finding those answers across a project board and an email thread takes effort. Sightline puts the current status, decisions and requests together on one page.
The constraint arrived before the design did. The client cannot be asked to make an account. That deletes the obvious answers in one go: no invitations, no seats, no notification settings, no second product for them to learn. Everything else in the system follows from it.
Two surfaces, one database, and a password on neither.
The studio side sits behind a magic link. The client side is one server-rendered page at /p/<slug>. The link grants access to that project, so anyone holding it can use the client page. There is no separate API tier. The studio's own pages are server-rendered already, so an HTTP layer in front of Postgres would have been a second place to write the same authorisation check.
That makes authorisation the design. The client can do exactly two things: mark a request done and decide an approval. Both use the project link, and the server scopes each action to that project. On the studio side, each child-row write carries the owning project and user in the same where clause. The permission check and the write are checked together.
The sign-in email links to a page with a button on it, not straight to the verify endpoint. Verification happens after that button is pressed, so simply opening the landing page does not consume the sign-in token. The stored tokens are hashed.
no account
slug-scoped
typed
source of truth
Five tables, and the rules worth having are constraints.
A client reads the page as a record of what was agreed. The schema's job is to stop that record and the interface disagreeing. Anything derivable is derived, and anything that has to happen together happens in one transaction.