Agency tools stack: client portal, billing, deliverables

Walk into most agencies and you'll find the same setup: one tool for the client portal, another for file delivery, a third for invoicing, and — somehow, still — PDFs going out over email. Each tool charges per seat, and the seats multiply with every client.

You can fold all of it into one small app. Here's the stack we'd build, and the one trap — access control — that you cannot get wrong.

What the portal actually needs

Three purchased subscriptions collapse into one codebase you own and brand.

Why this stack

Projects and deliverables as real records

The core model is small: a client has projects, a project has deliverables, a deliverable is a file plus some status. A managed data layer gives you those records and the file uploads with signed URLs, so a client downloads a polished asset through a link that expires — not an email attachment.

Invoicing belongs to Stripe

Agencies bill two ways: retainers and project fees. Stripe does both. Model each project with a reference to a Stripe customer, and let Stripe own the schedule, the dunning, and the receipts. You display status; you don't reimplement billing.

Access control is the whole game

Here's the part that matters more than anything else in this build:

A client portal is a promise that Client A can never see Client B's work. That promise is kept on the server or it isn't kept at all. Filter every deliverable query by the authenticated client's id, server-side. Hiding a button is decoration, not security.

Use the session user id on every read and write. The auth session exposes the logged-in user; resolve that to a client record and scope every query to it. A deliverable fetched by id must also match the owner, or it returns nothing.

Role-based views from one codebase

Your team needs an admin view; clients need their own slice. Same app, two roles. The admin sees all projects; the client sees only theirs. Branch on role at the data layer, not just the navigation, and you get a staff tool and a client tool from one deploy.

Wiring it together

 Client login (Better Auth)
      |
      v
  session.user.id ──▶ resolve client record
      |
      v
  Next.js /api: query projects WHERE owner = client
      |                         \
      v                          v
  deliverables (signed file URLs)  Stripe (invoices/status)

Stack risks

• Broken access control. The single highest-stakes bug in a portal. Scope every query server-side and write a test that proves Client A gets a 404 for Client B's deliverable.
• File link leakage. Signed URLs expire — use short lifetimes for sensitive deliverables and regenerate on demand rather than emailing permanent links.
• Scope creep into a full PM tool. It's tempting to grow this into Asana. Resist. The portal's job is delivery and billing; keep project management wherever your team already lives.
• Onboarding friction. A portal clients won't log into is worse than email. Make first login one click and the dashboard obvious.

Cost reality

One managed data-layer plan plus Stripe's per-transaction fee typically lands under what a single mid-tier portal SaaS charges per seat — and it doesn't climb with every client you add. The savings are real and they compound.

Your move:

Build the access-control check first — prove a logged-in client cannot fetch another client's deliverable — before you make a single screen look nice.