Lumen Portal.

Client work doesn't fall apart because the deliverable is bad. It falls apart in the gaps around it. A revision note lives in a text message. A final logo file lives in a Google Drive link that expires. A signed statement of work lives in a DocuSign account the client never gets access to again. Six weeks in, nobody, including me, can answer "where do things actually stand" without opening four different tools.

The worst version of this is the contract. Most solo operators and small agencies either sign things over email (no audit trail, no tamper protection, arguably not enforceable) or pay for a signing tool that lives completely outside the project. The client signs in DocuSign, then goes back to Slack for the actual work. Two systems, two logins, and the signed document has no connection to the deliverables it describes.

None of this is a client problem. It's an operator problem that clients experience as a lack of professionalism. A scattered engagement reads as a small, disorganized shop even when the work itself is excellent.

Lumen Portal is the single client-facing surface that sits on top of Orbit's data. Orbit is where I run the business, deals, pipeline, tasks. Lumen is what the client actually sees: their board, their files, their docs, their reports, all scoped to one workspace with their branding on it. When a deal closes in Orbit, a signed webhook provisions a Lumen workspace automatically and the client gets a magic-link invite. No separate onboarding, no separate account creation on my end.

The decision that shaped the last month of work was building agreements and e-signatures myself instead of embedding a vendor. An embedded signing widget solves the UI problem but not the trust problem, you're still asking the client to believe a third party did the right thing with the document. Building it in-house meant the agreement is just a doc row with `doc_type='agreement'`, so it gets the same editor, the same folder structure, and the same access model as everything else in the portal, plus a lifecycle: draft, sent, signed, with void and reopen for the admin. Every state transition runs through a SECURITY DEFINER Postgres function, `send_agreement`, `sign_document`, `void_agreement`, `reopen_agreement`, so the security boundary lives in the database, not in a client-side check that a modified request could skip.

The same philosophy runs through storage. The `media` bucket that holds every client file was public when I first shipped it, which is the default in most Supabase starters and a real hole once real client work is flowing through it. I moved it to private with signed URLs that expire, which meant rewriting how every image and file reference gets stored and rendered, not just flipping a flag. Documents in the rich-text editor now store the storage path, never the URL, and a render-time hook signs it fresh. A URL that expires can't accidentally get baked into a permanent document.

I also chose RPC-first mutations over letting the client talk to tables directly wherever the action matters, who can sign, who can void, who can see a report before it's sent. Row-level security policies handle read access well, but anything with a lifecycle or an audit requirement gets a dedicated function with an explicit identity check and an explicit grant. That's slower to build than opening a table up to `authenticated` and trusting the UI to behave, but it means a client can't forge a signature or alter a sent contract no matter what they send the API directly.

The files, docs, and reports were originally three separate rail items with their own routes. As the portal grew I consolidated them into one Files hub with tabs, on real nested routes rather than local tab state, so deep links, notification links, and the command palette all still resolve correctly. The three data models stayed separate underneath. Consolidation of the interface, not a merge of the data.

Lumen Portal is live at v0.36.1, built as the client-facing layer for every active engagement. A client logs in once and sees their board, their files with full version history, their docs, their sent reports with read receipts, and now, agreements they can review and sign inside the same portal, with a lock and an audit trail that hold up because the database enforces them, not because a UI button happens to be disabled.

The files that matter, contracts, deliverables, revision history, live in one place with private storage instead of a public bucket and a signing step instead of an email chain. Nothing here required a paid signing tool, a separate file-sharing service, or a second login for the client to keep track of.

1. A public storage bucket usually has two doors, the bucket flag and the RLS policy, and closing one without checking the other looks like a fix and isn't.
2. Anything with a lifecycle, especially signatures, should mutate through a database function with an explicit identity check, not a table the client can write to directly.
3. A raise inside a Postgres RPC rolls back that whole call's writes, so audit-then-reject logic has to return a status, not raise after recording the attempt.
4. Store a reference, not a URL, whenever the thing behind the URL can expire. A path signed at render time can't be accidentally frozen into a document.
5. Dry-run a production migration inside a transaction that force-aborts before you run it for real. It surfaces the exact row counts you're about to change with nothing written yet.
6. An audit trail should only record what the server can actually vouch for. A field you can't verify server-side is worse than an empty one.

This is what it looks like to take client trust seriously past the point of "it works in the demo." Storage that's actually private, signatures that are actually locked, and mutations that can't be forged from the browser console, are the parts that never show up in a screenshot and are exactly what a security-minded client or hiring manager checks for first.