A product succeeds or fails on whether the people who have to use it every day want to. These features ship with every application, permission-aware from the first day, and they are the difference between software people tolerate and software they open first.
Observations generated from records, inheriting their permissions from the source record. An insight drawn from something you cannot see never reaches you — the access control is structural, not a filter applied to the feed.
A per-user feed of what changed since they last looked, so 'did anything happen while I was out' takes five seconds instead of a walk through six modules.
Pin the records and pages someone works from daily. If their access to a record is later revoked, it vanishes from their favorites automatically — the shortcut cannot outlive the permission.
Search returns what the person can see and nothing else, because search goes through the same access function as every other read path.
The end-user guides in the documentation are written to be shared with the companies using your application, or rebranded as your own.
One of the quieter costs of launching a SaaS product is writing user documentation for it. Ten end-user articles already exist covering signing in, the inbox, AI suggestions and approvals, the insights feed, records and search, notifications, favorites, and data download — written deliberately without platform branding so you can share them directly or adapt them.
Your customers' users never need to know what the application was built on. Nothing on their screen says so, and nothing in the documentation they read has to either.
They work by default. What a user sees is determined by their permissions, which you were setting up anyway.
Yes. The end-user section is written to be shared or rebranded, deliberately without platform branding.
No. Insights inherit access from the record they were generated against, so an inaccessible source produces an insight the user never sees.
Create an account, explore the full builder console, and launch your first application on a custom domain. Nothing is charged while your application is still in development.
No credit card required. The console preview, the documentation, and the architecture reference are all readable before you sign up.
Get started free Read the docsCompose React pages in the Puck page designer, configure themes, assets, menus and User Types, and publish a reviewed page version. User Types select the experience; DataRoles and Locations control access to business records. A saved draft is separate from the version customers see.
Read the guideAuthorized builders can open + Debug to inspect safe outcomes, timing and correlation references, then follow a problem into app Logs. Share the sanitized support export rather than customer payloads, tokens or screenshots of secrets. Closing a problem preserves its history, and later occurrences can reopen it.
Read the guide