Prompt Kits

Build a Client Portal

A client portal replaces scattered attachments and status-chasing emails with one private place for each client. Its value depends on one promise: client A can never see client B's documents, messages or work, even with a copied address. This kit builds the public site first, proves that privacy boundary with two harmless test accounts, and only then adds document exchange, project or case status, messaging and notifications. Do not put real confidential material into the portal until the step 2 test passes, and get security, privacy and record-keeping advice appropriate to your profession and the places where you work.

Project type: Client portal Difficulty: Intermediate Time: 2-3 days Works with: Base44 / Lovable / v0

What you'll have at the end

  • A public service-business site that explains what the portal is for and what clients should expect
  • Invite-only client accounts, with each client restricted to their own private area
  • Document exchange in both directions without sending confidential files as email attachments
  • A project or case view showing current status, recent updates and what the client needs to do next
  • Private messages connected to the right client and the right piece of work
  • Useful notifications that say something changed without exposing confidential content in email
  • An owner area for clients, documents, statuses, messages and outstanding actions

Before you start

  • Your portal boundary. Decide what belongs in the portal and what must stay in another approved system. Requirements vary by profession and location, so get advice appropriate to the work you do before storing real confidential material.
  • Two test email addresses. One represents client A and one client B. Use invented names and harmless test content so you can try to cross the privacy boundary safely.
  • A simple client structure. Decide whether one client can have several projects or cases, which staff may work with each client, and which information clients should never see.
  • Your document rules. List the file types and sizes you accept, how long you keep files, who may delete or replace them, and whether your profession requires additional review, scanning, signing or record retention.
  • Your client-facing statuses. Choose a short set such as [YOUR STATUS NAMES], and write what each one means in ordinary language.
  • An email delivery service. Portal notifications should link people back to the portal rather than attaching documents or copying confidential messages into email.
  • Real public-site content and images. Prepare your services, contact details and real photos you own or have permission to use. Until then, use labelled placeholders only.

Which platform suits this

Base44 is the strongest fit because account login, saved client information, detailed access rules, file uploads and email can live in one app. That reduces the number of services to connect, but it does not make a portal confidential automatically—the client-to-client test in step 2 is still mandatory. Lovable can build the full portal with authentication, saved data, private file storage and scheduled notification work. Be explicit about access rules for every client item and test them after each later step. v0 can build the interface and full-stack logic and connect database and file-storage services, but you have more responsibility for choosing, connecting and securing those pieces. On any platform, use a specialist client system or arrange a professional security review when your work has strict confidentiality, signing, retention, audit or regulatory requirements.

The steps

1

Build the public site and explain the portal

When to use this

Start here, in a brand-new project, before accounts or client material.

A credible public site that sets the right expectations without pretending the private portal exists yet.

The prompt

Build a public website for [BUSINESS NAME], a [TYPE OF SERVICE BUSINESS] that helps [WHO YOU SERVE] with [WHAT YOU DO].

Create a home page explaining the service and the next step, a services page, a page for one service, an about page, a contact page and a how the client portal works page. The portal page should explain that invited clients will be able to exchange documents, check progress and send messages in one private place.

Add a client login button in the header and on the portal page. For now it should open a clear message saying that client access is being added next. Do not create a fake login or a private area that is not protected.

The public contact form collects only [PUBLIC ENQUIRY FIELDS]. Put a clear note beside it telling people not to send confidential details or documents through this public form. Do not add a file upload to the public form.

Store my services as editable information with a private owner screen. Each service has a name, short description, full description, who it is for and whether it is currently offered. Add three example services clearly labelled for me to replace.

Design the site to feel [THREE ADJECTIVES] using [COLORS]. Make it easy to read on a phone. Use labelled placeholders saying [REAL BUSINESS PHOTO NEEDED]. Do not use stock photography and do not generate images of clients, staff, documents, offices or results from scratch. Editing my own real business photos is fine; only invented or generated scenes are the problem.

Do not add client accounts, documents, project records, messages or notifications in this step. When finished, tell me where I edit services and which words and images are still examples.

Check it worked

  • Every public page opens and the menu works
  • The portal page explains what invited clients will be able to do
  • The client login button does not pretend an unfinished portal is ready
  • The public contact form warns people not to send confidential material
  • Editing a service changes the public service page
  • Every missing image is a clearly labelled request for a real image
  • The site reads and taps comfortably on your phone

You'll know it worked when:

A public site where a prospective client understands your service and the portal promise without being invited to share confidential material yet.

Watch out for

A public enquiry form is not a confidential intake system. Keep it short, remove file uploads and direct existing clients to the portal only after the access test passes. Do not describe the portal as secure merely because a login screen is planned.

2

Prove one client can never reach another client's material

When to use this

Immediately after the public site is right, before adding real documents, projects or messages.

An enforced privacy boundary that works even when someone pastes another client's address.

The prompt

Add invite-only client accounts and the private access boundary for this portal.

Use the platform's built-in account system for login, logout and forgotten-password reset. I create each client in a private owner area and invite their approved email address. Do not allow open public sign-up. An invited account belongs to exactly one client area unless I explicitly assign it to more than one.

Create a private client home page that shows only that client's name and harmless test items for now. Add two invented test clients using [CLIENT A TEST EMAIL] and [CLIENT B TEST EMAIL]. Give each one a clearly labelled dummy note and dummy document reference containing no real client information.

Enforce access on the material itself, not only by hiding menu links. Before showing a client area, note, document reference or future download, check that the signed-in account belongs to that exact client. Client A must never receive client B's title, file name, status, message, contact detail or any hint that the material exists.

Add owner and staff access using [YOUR STAFF ACCESS RULE]. Only I can create clients, send invitations or change which account belongs to which client. A staff member sees only [ALL CLIENTS / ASSIGNED CLIENTS]. A client can never change their own client assignment or staff permissions.

Make private material unavailable when signed out. If someone pastes an address for material they cannot access, show a neutral not available message or return them to their own portal without revealing whose material it was.

Do not add real uploads, project tracking or messages yet. When finished, give me a plain-language test plan using the two test accounts, including the exact client-area and dummy-item addresses I should copy between them.

Check it worked

  • Client A logs in and sees only client A's name and dummy items
  • While logged in as client A, pasting client B's private-area address reveals nothing about client B
  • Pasting client B's dummy-item address as client A also reveals nothing
  • Client B passes the same tests against client A's material
  • Signed out, neither client's private address shows its content
  • A client cannot change their assignment or open the owner and staff controls
  • A staff test account follows the client visibility rule you chose
  • Forgotten-password reset works without exposing whether another person is a client

You'll know it worked when:

Logged in as client A, you pasted client B's private-area and dummy-item addresses and both were refused without revealing any client B information, then repeated the test in the other direction.

Watch out for

Hiding a link is not confidentiality. The check must happen every time material is opened, including through a pasted address or future download. Test with ordinary client accounts, never your owner account, because the owner is supposed to see more. Keep the two test accounts for every later step; document, status and messaging changes can reopen the boundary.

3

Exchange documents safely in both directions

When to use this

Only after the two-client privacy test passes.

Clients and staff can exchange files without creating public links or sending confidential attachments by email.

The prompt

Add private document exchange to the client portal without weakening the access rules from step 2.

I can upload a document to one chosen client and optionally connect it to [PROJECT OR CASE TERM]. A client can upload a document only into their own client area. Every document shows a clear title, category, who uploaded it, when it was uploaded, which client and project it belongs to, its current version and [DOCUMENT STATUS NAMES].

Store documents in private storage. Opening or downloading a document must check the signed-in account and client assignment again at that moment. Do not expose a permanent public file address. A copied download address from client B must not work for client A or while signed out.

Accept only [ALLOWED FILE TYPES] up to [MAXIMUM FILE SIZE]. Reject unsupported or oversized files with a useful explanation. If the chosen storage setup cannot check uploaded files for malware, which means harmful files, stop and tell me plainly what separate protection or review I need before accepting real uploads. Do not claim a file is safe merely because it uploaded successfully.

Let either side upload a new version without silently erasing the earlier one. Show which version is current and keep the earlier history for [YOUR RETENTION RULE]. A client may remove their own unsubmitted upload, but cannot delete a document I shared or erase the activity history. I can archive a document without breaking the rest of the client record.

Notify the other side that a document is available using a generic email that links back to the portal. Do not attach the file and do not include its confidential contents in the email.

Test with one harmless file uploaded by client A, one harmless file I share with client B, one unsupported file and one oversized test file. Re-run the crossed-address test using both the document page and its download address.

Check it worked

  • Client A can upload a harmless test document and you can open it from the owner area
  • You can share a harmless test document with client B and client B can download it
  • Client A cannot see client B's file name, document page or download when given the copied addresses
  • Signed out, a copied download address does not open the file
  • An unsupported or oversized file is refused with a useful message
  • Uploading a new version keeps the earlier version visible in the history
  • The notification email arrives without the document attached or its confidential contents exposed

You'll know it worked when:

A two-way test exchange where client A uploads to you, you share with client B, and copied client B document and download addresses reveal nothing to client A.

Watch out for

A difficult-to-guess file link is still a public link if it opens without checking the account. Test the download itself, not just the document page. File storage also does not automatically provide malware checking, retention rules or professional compliance; confirm those separately before using real material. Email notifications should say that portal activity is waiting, not repeat confidential names or contents.

4

Show project or case status without exposing internal notes

When to use this

After private document exchange works in both directions.

A client can answer “where does this stand?” and “what do I need to do?” without emailing you.

The prompt

Add client-facing progress tracking to the portal. Use the word [PROJECT / CASE / ENGAGEMENT / YOUR TERM] throughout.

In my owner area, I can create a piece of work for one client with a title, responsible staff member, start date, current client-facing status, last update, next step, target date when appropriate and whether the client owes an action. Use only these client-facing statuses: [YOUR STATUS NAMES AND PLAIN-LANGUAGE MEANINGS].

On the client side, show their active work first. Each item shows the current status, the latest client-facing update, what happens next, any action they need to take and when it was last updated. Connect the right shared documents to the right item.

Keep client-facing updates completely separate from private staff notes. Private notes, internal risk labels, staff discussion, other clients, private fees and draft decisions must never appear in the client view, search, notifications or copied addresses.

Keep a dated history of client-facing status changes so the client can understand progress. Do not delete an earlier update when the status changes. Let me correct a mistaken update while preserving that a correction was made.

Do not invent target dates or imply a guaranteed outcome. If no reliable date exists, show [YOUR NO-DATE WORDING] rather than guessing.

Test one active item and one completed item for each test client. Re-run the client A versus client B address test on the item page and on a connected document.

Check it worked

  • Client A sees only client A's active and completed work
  • The current status, latest update, next step and client action are understandable without explanation
  • Changing a status adds to the dated history instead of erasing the earlier update
  • A private staff note never appears in the client view or notification
  • Client A cannot open client B's item by pasting its address
  • A connected document still follows the document permissions from step 3
  • Missing target dates use your honest wording rather than an invented promise

You'll know it worked when:

Each test client can open one piece of work, understand its current status and next action, and still cannot reach the other client's work by pasted address.

Watch out for

One notes field for both staff and clients is a confidentiality accident waiting to happen. Keep private notes and client-facing updates separate from the start. Statuses also become useless when nobody updates them, so show the last-updated date and include stale items in the owner view rather than presenting old information as current.

5

Add private messaging and useful notifications

When to use this

Once accounts, documents and status pages have all passed the crossed-client tests.

Clients and staff can communicate around the work while email carries only a safe notification.

The prompt

Add private portal messaging, notifications and an owner activity view.

Each message belongs to one client and, when relevant, one [PROJECT OR CASE TERM]. Clients can start a message and reply only inside their own client area. Staff can message only clients allowed by [YOUR STAFF ACCESS RULE]. Show sender, date, message, unread state and the related work item in a clear conversation.

If a message includes a file, send it through the protected document flow from step 3 rather than adding an ordinary public attachment. The same client check must protect the message, conversation and file every time they are opened.

Send notifications for [EVENTS THAT SHOULD NOTIFY, e.g. new message, new document, status change and action due]. Use in-app notifications and [EMAIL / NO EMAIL]. An email should say only that new portal activity is waiting, name [SAFE DETAILS ALLOWED IN EMAIL] and link to the login page. Do not copy the full message, confidential document name or sensitive status into email.

Prevent duplicate notifications when an action is retried. Do not send a notification to the person who performed the action. Let each person mark items read, and let clients control [OPTIONAL NOTIFICATION PREFERENCES] without turning off essential account or security messages.

Give me one owner view of unread client messages, documents awaiting review, client actions due and work items not updated since [STALE PERIOD]. Opening an item should take me to the correct client and preserve the full dated history.

Keep archived conversations and notification history according to [YOUR RETENTION RULE]. Do not let a client delete staff messages or erase the history.

Test a message, reply, document attachment, status notification and due-action reminder with both test clients. Then repeat every client A versus client B direct-address test from steps 2 through 4.

Check it worked

  • Client A can message you and see your reply in the same conversation
  • A file added to a message follows the protected document flow
  • Client A cannot open client B's conversation or attachment from copied addresses
  • The notification email arrives but does not reveal the confidential message or document content
  • The person who made the change does not receive a pointless notification about their own action
  • Repeating the same action does not send a duplicate message
  • Your owner view shows unread messages, documents awaiting review, due client actions and stale work
  • Every earlier crossed-client test still passes

You'll know it worked when:

A complete test conversation with a protected attachment and notification where each client sees only their own activity and every crossed-client address remains blocked.

Watch out for

Email is the alert, not the portal. Copying full messages or document names into notifications recreates the confidentiality problem the portal was meant to solve. Duplicate alerts destroy trust quickly, so test the same event twice. Re-run the privacy tests after messaging because conversations and attachments introduce new ways to request client material.

Going live

  • Replace every example service and public image placeholder with accurate copy and real images you own or have permission to use
  • Remove every dummy client, note and document before inviting real clients, while keeping separate harmless test accounts for future checks
  • Repeat the client A versus client B test on the live site for the client area, project or case, document page, download address, conversation and attachment
  • Repeat the crossed-client test for every staff role and after changing a staff member's client assignment
  • Confirm that a removed client or staff account immediately loses access to previously available material
  • Test login, logout and forgotten-password reset from a private browser window
  • Test allowed, unsupported and oversized files, and confirm what malware protection or manual review your setup actually provides
  • Confirm notifications contain only the safe details you approved and never attach confidential documents
  • Write and follow a retention, correction, deletion and backup process appropriate to your work
  • Get privacy, security and professional-confidentiality advice appropriate to your profession and location before storing real client material
  • Run the access rules audit after every meaningful portal change
  • Connect and verify your email service with the transactional email prompt
  • Add your privacy policy and terms with the legal pages prompt
  • Connect your custom domain with the custom domain prompt and confirm the padlock appears

Spend fewer credits

Every builder charges you for the work its AI does — so the cheapest habit is thinking before you build. These six rules cut most of the waste, whichever platform you choose.

  1. Plan in a free chat first. Sketch the whole thing in ChatGPT, Claude or Gemini — pages, features, what each form collects, what it should look like. Thinking there is free; thinking inside a builder is billed.
  2. Start from a written prompt, not a sentence. "Make me a website" is the most expensive sentence in AI building. A complete first prompt — like the ones on this site — saves dozens of correction rounds.
  3. Don't be lazy with the details. Every detail you leave out comes back as a correction you pay for. Business name, colors, every page, every form field, what happens after someone submits — put it all in the first prompt.
  4. One change per message afterwards. "Fix the header, and the form, and the colors" produces a tangle that costs more to unpick than it saved.
  5. Stuck? Stop patching. If the same fix fails about three times, don't send a fourth correction — describe the whole section's desired end state in one fresh message instead.
  6. Build on the free tier, pay to publish. Every major platform lets you build and see your site for free. Upgrade when you're ready to put it on your own domain — not before.

The prompts on this page are written to do most of this work for you — that's the point of them.

Read the full guide

Last reviewed: 2026-07-27

FAQ