Security

Your matrix is the most valuable thing you own.

A shop's pricing, payroll and customer list are commercially sensitive. Isolation is enforced inside the database itself, not merely in the application — so a bug in a screen cannot become a leak between shops.

Isolation

One shop cannot see another. Structurally.

Every record carries the organization it belongs to, and the database refuses to return rows from any other — regardless of what the application asks for. Switch shops below: the query does not change, and the answer does.

Signed in as

select * from insurance_pricing_matrix;no where clause

Shop	Panel	Size	Band	Price
Cedar Ridge	Hood	Quarter	Moderate	$225.00
Gulf Coast	—	—	—	not returned
Cedar Ridge	Roof	Nickel	Medium	$400.00
Gulf Coast	—	—	—	not returned
Cedar Ridge	Left Fender	Dime	Light	$100.00
Gulf Coast	—	—	—	not returned

The query asked for everything and got three rows. The filter is a policy on the table, not a clause in the query — so code that forgot to scope, or a token used somewhere it shouldn't be, still cannot reach another shop's prices.

Row-level isolation

Postgres row-level security is applied to every table. A query for another shop's repair orders returns nothing, even if the code asking is wrong.

Two independent gates

Server actions verify who is calling and what role they hold; the database re-checks every row independently. Neither is trusted alone.

Role-gated by design

Compensation, pricing, org settings and staff roles are restricted to owners and admins — enforced in the database as well as in the interface, so it cannot be bypassed by calling the API directly.

The record

An audit trail you can stand behind.

Estimates decide what a carrier pays and what a technician earns, so the history of one has to be defensible.

Locked versions: Once an estimate is sent it becomes immutable. Changes go through a supplement with a reason code, so the version that priced the job is preserved exactly.
Every save checkpointed: What changed, who changed it, and the total at the time — restorable in one click.
Concurrent edits caught: If two estimators open the same estimate, the second save is rejected rather than silently overwriting the first.
Activity trail per RO: Status changes, edits, supplement creation and approval, and facility-fee changes are all recorded with who and when.
One calculation: Every figure on every surface comes from the same money engine, so the screen, the PDF, payroll and the invoice cannot disagree.

Handling

Credentials, sharing and export.

Customer links are narrow

A shared estimate link carries a high-entropy token, is never indexed, is revocable at any time, and exposes only what a customer should see — never cost, commission, splits or internal notes.

Secrets stay server-side

Messaging credentials are stored per shop and never reach the browser; identifiers are masked before display.

Your data is yours

Estimates and documents export as PDF, payroll and reports as CSV, on demand and without a fee.

How we work

Security is reviewed, not assumed.

Isolation is verified against the live database rather than taken on trust, and findings are fixed at the layer that actually enforces them.

Database migrations that touch access or membership are reviewed before they are applied and verified against the live schema afterwards. Every function that runs with elevated privileges has its search path pinned and its direct execution revoked. Anything that bypasses row-level security is enumerated, justified and returns an explicit list of fields rather than whole records.

We would rather find a problem in review than in the field, and we would rather tell you what is not yet built than let you discover it.

Questions from your IT or your carrier?

Ask us anything about how isolation, retention or export works. We will answer specifically.

Ask a question See the features