Custody
You are holding someone else's books. These are the four decisions we made before writing the product, because they are the ones that cannot be retrofitted afterwards. None of them are certifications or promises about intent — they are properties of how the thing is built, and each names the file that enforces it.
Your client's money never touches us
Invoices are produced here and sent by you, carrying your own wire and ACH details. Funds move directly between you and your client. We are not a party to that transfer, we hold no balance on your behalf, and there is no account here for money to sit in.
This is why we do not use Stripe Connect or any other multi-party fund routing, and will not: the moment a platform sits in the flow of client money it acquires obligations — and a failure mode — that have nothing to do with running a fractional practice.
One workspace cannot read another
Every table that carries your work — retainers, clients, initiatives, invoices, documents — has an executive_id column and a row-level security policy in Postgres that scopes it to the signed-in user. The check happens in the database, not in application code.
The distinction matters more than it sounds. Isolation enforced in application code holds until somebody writes a query that forgets to filter, and that is the single most common way multi-tenant products leak. Here the database refuses the read regardless of what the application asks it for. The policies are in docs/schema.sql and apply to every tenant table without exception.
We hold no payment keys at all
There is no payment processor to connect and no API key to hand over. We do not ask for one, there is nowhere to enter one, and there is nothing stored that could be used to move money in your name or in your client’s.
An earlier build did offer this — connect your own Stripe account, key encrypted at rest in a vault. We removed it. A payment secret is not read-only: it can create charges and read every customer on the account. Encrypting it protects a database at rest but not a running application, which has to decrypt it to use it. Holding one of those per practice was the largest thing we could be trusted with, and the invoices this product exists for are five figures a month and settled by bank transfer, not by card. So the safest version of that feature turned out to be its absence.
A client portal sees one engagement
Your client signs in with a magic link sent to the address on their record — no password for them to reuse or for us to store. What they can then read is decided by the same row-level policies, matched on the email in their token against the client record on the retainer.
A portal session cannot reach:
- any other client of yours, or any other executive's clients
- your capacity, your total revenue, or your other retainers
- invoices you have drafted but not issued
What this page does not claim
We are not going to put a certification badge here that we have not earned. There is no SOC 2 report today; if you need one before you can buy, say so and we will tell you honestly where we are rather than imply otherwise. Nothing above describes a roadmap — it describes what the code does now, and you are welcome to ask us to walk you through any of it.
Questions, or a security issue to report: support@valzeo.com. We would much rather hear from you than not.