Preview deployments your non-technical stakeholders can actually review
Most preview tools assume the reviewer is an engineer. PrimDB turns every pull request into a live preview a founder, designer, or client can comment on, then gates production on a real approval.
A preview URL is only useful if the right person can act on it. For engineers, a diff and a staging link are enough. For the people who often decide whether a change is right, a founder, a designer, a client, a diff is noise and a screenshot in chat is a downgrade of the real thing.
The preview is the running app
On PrimDB, every pull request builds into its own isolated preview URL. It is the real app on a real data branch, not an image and not production. A stakeholder opens the link and sees exactly what will ship.
Comments pinned to the page
A feedback overlay is injected into the preview at the proxy level, so there are no app changes to make and no framework to special-case. A reviewer clicks any element and leaves a note pinned to that exact spot.
- No GitHub account, no repo access, no local setup.
- The comment is tied to the element they clicked, not a paragraph of vague description.
- Notes are stored per route as Markdown, so a developer or an agent reads exactly what to fix.
Approval before anything ships
Feedback is only half the loop. The other half is making sure nothing goes live before the right person says so. Promotion to production is approval-gated: the preview stays a preview until an owner reviews the notes and approves. One click promotes, one click rolls back.
Because the preview a reviewer commented on is the exact build that promotes, sign-off means what it says. The comment and the release live on the same pull request.
Honest note. This works on any framework, because the overlay is added by the relay proxy rather than your code. It is injected on preview and test URLs only, never on production.
See the full flow on the Preview & feedback page, or the mechanics in the docs.