Using Mycel

What your client sees

Your client never hears about us. They get a link to a portal on your domain, with your name and your brand on it, holding the work you signed.

The one thing worth understanding

A deliverable moves through a fixed set of states, and it matters who owns each move:

drafting ──submit──▶ in_review ──release──▶ with client ──accept──▶ accepted
   ▲                   │                      │
   └──── reject ───────┘                      └──request changes──▶ changes requested
   ▲                                                                       │
   └───────────────────── submit (next version) ──────────────────────────┘

• You own exactly one move: in_review → with client. That is the release. It is the only edge Mycel will not take for you.
• Your client owns the two moves out of with client:accept, or ask for changes. Nothing inside your business can mark work accepted — not you, not an agent, not an admin. That is what makes “accepted” worth invoicing against.

Why an unreleased draft is not merely hidden

The portal does not filter unreleased versions out of a list. It cannot reach them at all: the release timestamp is the read filter itself, so an unreleased version is unreadable by id and its files return 404. There is no list route to forget and no by-id route to leak through.

This matters because “hidden in the UI” is how documents leak, and it has happened to other people twice for exactly that reason.

Setting up the portal on your own domain

Under Settings → Addresses you will find the portal link and the DNS record to point your own subdomain at it. Until you do, the link works on ours — clients can be using it the same day.

What the client can do there

• Read and download the deliverable, in every version you released.
• Accept it, or ask for changes with a note.
• Answer anything the work is waiting on — a missing statement, a figure you need.
• See their invoices, if you bill through Mycel.