Welivo runs on Postgres hosted in the EU with row-level security on every table. Managers never see individual confirmations. Reps' answers are final. Every entry in the audit log is hashed with the one before it, so a change to any past entry breaks every hash after it. Retention is set by you, per organisation.
Hosting
The database is Postgres, hosted in the EU. The application runs on Vercel. Transactional email (the Friday confirmation, the 08:00 digest) is sent through Resend from the EU region. We do not run our own servers and we do not store data outside the EU.
Who can see what
| Role | Sees | Never sees |
|---|---|---|
| Rep | Their manager's commitments to them, the confirmation email, their own signed reviews and the figures behind them | Anyone else's data. Their manager's rate |
| Manager | Their own follow-through rate, their team's targets and pace, their own coaching log, disputes a rep chooses to share | Which rep said kept or not kept. Disputes not shared with them |
| Director / owner | Every manager's rate and team sheet, individual reps by name, the audit log | Nothing in their organisation is hidden from them |
| Ops admin | Setup, people, teams, disputes | Billing unless also owner |
| Welivo (us) | Health and errors. Tenant data only with your written permission for support | Your data in the normal course of running the service |
Every table has row-level security, which means the database itself refuses to return rows that do not belong to the organisation and role making the request. It is not a filter in the application that could be bypassed. It is enforced by Postgres.
The hash chain, in plain words
Every event that matters (a commitment made, a confirmation received, a review signed, a dispute logged) is written to an audit log. When it is written, we take the content of the entry plus the hash of the entry before it and run both through SHA-256. The result is stored with the entry.
That means each entry's hash depends on every entry that came before it. If anyone, including us, went back and changed one line, its hash would no longer match, and neither would the hash of every entry after it. The chain would show exactly where it broke. You can export the log and check it independently.
A signed review works the same way. The review, the figures attached to it and the rep's sign-off are hashed together and the hash goes in the log. If the figures are changed later, the hash no longer matches the signed version.
Retention
You set it, per organisation, in years. The default is six. When a record passes the retention date it is deleted from the live database and from backups at the next backup cycle. Leaver records are kept to the same rule, so a leaver's manager evidence is still there two years later if a claim arrives, and gone when you say it should be.
Reps and their data
Reps are not users. They have no login and no password. They receive emails at the address you give us, and each email carries a one-time link that records their answer. A rep can ask to see everything held about them, and a rep can see their own signed reviews at any time through a link. Their confirmations are never shown to their manager and are never changed after the fact.
Ask us
If your security team has a questionnaire, send it through the book page and it will be answered by the person who built the system. We are a small company and we would rather answer the real question than send you a badge.
See your Monday team sheet
Twenty minutes with the team. Bring your team structure, he shows you what your managers' follow-through would look like.