nobody outside yet. three of our own projects go first.
briven has no external customers. the three projects lined up to move onto it are flndrn's own, and none of them has moved yet. when someone else's product runs on briven, we will name it and publish numbers we measured.
a monitor writes a row every time it checks a site, which is the plainest possible postgres workload — lots of small inserts and time-ranged reads. it would talk to briven over the http sql endpoint with a read-only key for the dashboard and a write key for the checkers.
message history and attachments are a natural fit, and live delivery is one too now that briven pushes changes as they happen — 5 milliseconds from commit to delivery, measured on the live server. the part briven would not carry is the offline half: a client that has been shut for a day still needs something to catch it up when it opens.
compliance is the hard part here: every mutation needs to leave a trace, and access needs to be narrower than one shared login. organisations, custom roles and the audit log are the parts of briven this project would lean on hardest.
postgres 18custom rolesaudit log
being early should get you something
it gets you the person who wrote briven. tell us what you are building and you will get a straight answer on whether it can carry the work — and if it cannot, we will say so rather than take the signup. nothing you ask for sits behind another customer's request, because there is no queue yet.
or skip the conversation entirely: creating a database takes seconds, and the free plan never asks for a card.