Build a Softr client portal around real records and permissions

Start with the business job

Thanks to Softr for sponsoring this video.

A client portal needs to do more than display a convincing dashboard. Clients should be able to log in, find their own projects and invoices, and submit a request that reaches the right place. Those are the jobs behind this Softr walkthrough.

In the published demonstration, Codex and Claude Code connect through Softr’s MCP server to build a custom interface with vibe coding blocks. Softr provides the database, login and permission controls underneath. The clients and financial figures are fictional test data, rather than evidence of a live customer deployment.

Give the interface something real to read

The recorded sequence starts with projects, requests and invoices tables populated with test records. The project page is then prompted to use connected records instead of sample text. That distinction is central to the lesson: the page needs to reflect database state for its content to mean anything.

The description outlines the following workflow. It does not provide a complete field schema or the exact prompt, so this is a companion checklist rather than a copy-and-paste build specification.

1. Create the projects, requests and invoices tables and add fictional test records.
2. Build the project page against those connected records.
3. Set record filters so each client sees only their own projects, invoices and requests.
4. Build a request form that saves the project, email, date and status.
5. Connect an email notification workflow to new client requests.

Test the whole request journey

The walkthrough follows a request from the form into the database and then to its email notification. That gives the viewer a concrete sequence to inspect instead of stopping at a success message on the page. Each stage is part of the same business action.

It also checks separate client views, logged-out access and mobile layouts. These are distinct checks: a portal can look correct for one client while showing the wrong records to another, and a desktop layout says little about how someone will use it on a phone.

The closing review includes version history alongside those access and layout checks. The useful next step is to follow the linked video through each stage with test records before considering real client data. The published description reports the demonstration checks; it does not establish that a different portal inherits their results.

The takeaway

Build the interface around records and access rules, then trace a complete request through the system. Appearance is only one part of a usable client portal.