Prototype a client portal with demo data, then build the real logins
A client portal promises fewer "any update?" emails: clients log in and see where their project stands, what's waiting on them and what's been delivered. Anticode can build a working prototype of that experience with demo data, so you can agree the screens with a real client. Real client logins and private files need a backend, which the Next.js export provides as a starting point.
What clients actually want from a portal
Ask a few clients before designing anything. Their answers usually come down to four questions, and the portal should answer each without a click:
- Where are we? The current phase, the next milestone and its date.
- What do you need from me? Outstanding approvals, content, payments or answers, with due dates.
- What have you delivered? Files and links, newest first, with versions clearly labelled.
- What have we agreed? The scope, quotes and decisions, so nobody relies on memory.
Messaging is often requested and often regretted: a portal inbox competes with email, and clients end up writing in both. Many small firms do better with a simple "latest updates" feed from the team and email for conversation.
Screens to prototype
| Screen | What it shows |
|---|---|
| Overview | Phase, progress bar, next milestone, items waiting on the client |
| Timeline | Milestones with dates, done and upcoming |
| Approvals | Items to review with Approve and Request changes buttons, and a comment box |
| Files | Deliverables by phase, with version numbers and dates |
| Updates | Short posts from the team, newest first |
| Invoices | Amounts, due dates and status, with a link to pay |
Building the prototype
Describe your service and the screens: "A client portal prototype for a small architecture practice. Overview, timeline, approvals with approve and request-changes, a files list by phase, a team updates feed and invoices. One sample client, 'The Harlow Barn conversion', with realistic milestones and documents, all labelled demo data. A sign-in screen that's clearly a demo. Calm, Swiss-style layout."
The model writes the whole portal as one app that runs in the browser. Everything is clickable: approving a drawing moves it to the approved list, a comment appears in the thread, the progress bar moves. Anything that would involve a server, such as signing in, receiving a file or notifying the team, is simulated in the page and labelled. You can also give the portal your firm's look by naming a design direction, such as Swiss with Inter Tight.
Testing it with a client
Send a trusted client the published link and ask them to find three things: what's waiting on them, the latest drawings, and the next site visit date. Watch where they look first. For colleagues and stakeholders, a client review link opens the current preview without an account and collects comments tied to sections; it expires after 14 days by default and can be revoked. Make the changes in plain words and compare versions in version history.
What the prototype can't be
Because Anticode apps have no network, the portal prototype runs on one device with sample data. It can't:
- Sign real clients in or keep one client from seeing another's project.
- Receive uploads from clients or deliver your real files privately.
- Notify you when a client approves something, or notify them when you post.
- Take payments. A link to your payment provider can be placed on the invoices screen, but the status won't update itself.
- Show the same state to you and your client, since each browser keeps its own copy.
Don't put real client documents or personal data into it and send it out: anything in the page is visible to whoever has the link.
Turning it into a real portal
The Next.js export is the route Anticode offers. It covers app builds and produces a standard App Router project in TypeScript with Postgres through Prisma, email sign-in, customer and staff roles (your clients and your team, respectively), row-level security in Postgres so each client sees only their rows, an audit log, and an admin area with two-factor sign-in. Email is sent through Resend, and the README covers hosting on Neon, Supabase, Docker or Vercel.
A developer still has to build the portal's own features on top: projects per client, file storage, approval records, notifications. The tested prototype tells them exactly what to build. If you'd rather not commission development, a hosted client-portal product, or a shared folder with a clear naming convention, may be enough.
Questions people ask
Is this a client portal builder I can launch to clients today?
Not as a secure portal. Today it's a prototype for agreeing the design. Real logins come with the Next.js export and a developer's work on top.
Can each client see only their own project in the prototype?
The prototype can show the screens for one sample client, but it can't enforce privacy between clients. That needs real accounts and row-level security.
Can clients submit requests through it?
A contact or enquiry form in the app does reach you, by email and in the dashboard. Everything else in the prototype stays on the client's device.