Where your notes live.

To run a sheet: a VIN, or year, make and model, plus miles and the state the car sells in. For a Portfolio Scan or the monthly re-screen: a list of open notes with VIN, sale miles and sale date. For a backtest: the same fields plus one outcome per car, repossessed or paid off. That is the whole list.

We never receive a borrower’s name, address, date of birth, Social Security number, payment history, or any consumer credit data. A file that contains any of those columns is rejected and deleted, and we ask for it again without them. The sheet never sees a customer and never asks about one.

In a Postgres database hosted by Supabase in the United States, encrypted at rest and in transit. Sheets and scan results are computed on our servers and stored in the same database. Card and bank details are entered with the payment processor, never on our site and never in our database.

Two people: the founders, Patrick and Harrison. The application reads and writes the database through a server-side service role only. Note data is never read or written from the browser: it holds only the public auth key, which the database grants nothing. Each row is tied to your account and is served only to a signed-in session of that account.

Open-note lists are kept while the account is active, so the monthly re-screen has something to screen. When you cancel, the clock starts: your history stays exportable from the dashboard for 90 days, then a scheduled job deletes it and writes a purge event to the audit trail. You can export at any time before that, active or cancelled, and you can ask for deletion sooner.

Only aggregates, and only where the cell holds at least 20 units: for example, the share of a model year’s notes that sat in a complaint window. Never a dealer’s data individually, never a figure that could be traced back to one lot, and never anything about a dealer by name without that dealer’s written permission.

Session-token auth

Every request that touches account data carries a session token that is checked against the auth service before any read or write. The server then checks that the rows belong to that account.

Constant-time secret checks

Admin and service secrets are compared with a constant-time function, so a wrong guess takes the same time as a near miss and nothing leaks through timing.

Security headers on every response

Content-Security-Policy, Strict-Transport-Security with preload, X-Frame-Options DENY, and X-Content-Type-Options nosniff.

Row-level security, default deny

Row-level security is enabled on every table. No policy grants the anonymous or signed-in database roles anything, and the audit, lead, and sheet ledger tables have all access revoked from both on top of that. Only the server's service role reads and writes.

Audit trail

Account events (cancellation, export, reactivation, purge, and the like) are written to an account-events log tied to the account, which we can produce on request.

Cancel from the dashboard, which starts the 90-day clock on its own, or ask us directly and name the account. We confirm in writing when it is done.

Reply to any email we have sent you and say it is a deletion request.