Portal starter
A built-in starter with overview, projects, files, messages, and activity sections, held to that shape by a contract.
AI client portal builder
Give every client a portal you did not have to build twice.
Tervane generates a working client portal — projects, files, messages, and approvals — with access control that is enforced when the page is served, not hidden in the interface.
Password and member-restricted publishing.
Per-client records with derived access rules.
Custom domain on your own hostname.
Why portals are the wrong thing to hand-build
A client portal is mostly repetition. Every agency, studio, and consultancy needs the same nucleus — a place for the work in progress, the files, the conversation, and the sign-off — and every one of them ends up rebuilding it, badly, in whatever tool is nearest.
The interesting part is never the layout. It is the access rules: this client sees this project, that file is not visible until it is approved, and nobody who is not signed in sees any of it. That is exactly the part a generic page builder leaves to you.
Access enforced at serve time, not in the interface
A published portal can be public, password-protected, or restricted to named members of your workspace. That decision is enforced when the page is served: a restricted site returns nothing to an unauthenticated request, and it is marked so search engines do not index it either.
Inside the app, per-record access comes from the same derived policy layer the rest of the platform uses. The rules are generated from the validated data model rather than written by the language model, and the browser verification step drives two separate client sessions to confirm one cannot see the other's records before the build is accepted.
The starter is a contract, not a screenshot
Choosing the portal starter does not just set a colour palette. The starter declares its layout family and its named sections, and the generated app has to render them — the build fails and repairs itself if the model drops them.
That is why picking a starter here produces something recognisably the thing you picked, rather than a generic page wearing its colours.
On your domain, with your branding
Portals are client-facing, so they should not live on someone else's subdomain. Verified custom domains are supported with automatic certificates, and the published site carries your title, description, and social image.
Every published version is kept, with the file-level differences between them, so restoring last week's portal is a click rather than a rebuild.
Frequently asked questions
- Can clients sign in and see only their own work?
- Yes. Declare the roles and the per-client relationship in the model, and access rules are derived from it. Cross-client isolation is exercised in a real browser with two separate sessions before the build is accepted.
- Can I keep the portal off the public internet?
- Publish it behind a password or restrict it to named members of your workspace. Restricted sites are served only to authorised requests and are marked as non-indexable.
- Can it run on our own domain?
- Yes — verified custom domains with automatic certificate provisioning, so the portal lives on a hostname your clients already trust.
- How do we change it once clients are using it?
- Presentation changes apply deterministically with no model call and no rebuild. Structural changes go through the reviewed path, and every version is saved so a bad change is reversible.