Teams and security
Roles, sharing and two people in one deal, with a history nobody can rewrite. And deals encrypted under your firm's own key before they are stored.
For a firm
Built for a team, not a seat
Roles, sharing, two people in one deal, and a history nobody can rewrite. Open any line for how it works.
Organizations and roles
Four roles, per-deal sharing, invitations and seat management.
Four roles, per-deal sharing, email invitations and seat management. An owner can reset a member's two-factor authentication when they have lost both their phone and their recovery codes, with an email naming who did it, a session revocation, and an audit entry recording both sides.
Your name on it
Your logo, name and color on the app and both exports.
Your logo, company name and brand color across the application and both export formats. The accent is contrast-solved against the surface it lands on, so a dark brand color cannot become unreadable text. A small “Powered by Waynick Underwriting” stays in the export footer.
Two people, one deal
Autosave and live presence, and a conflict never destroys anyone’s work.
Autosave, optimistic concurrency and live presence: a colleague's focused field is ringed and named. A conflict is never resolved by destroying work. Whichever button you press, your version is kept in history or forked into a deal of its own.
Every save is a version
History only grows: restoring adds a revision rather than rewinding one.
Restoring adds a revision rather than rewinding one, so history is append-only and nothing is lost by going back. A save from a client older than the stored deal is refused outright, because a field silently dropped by an out-of-date tab is worse than an error message.
A pipeline you can actually search
Search, filter and rank every deal on figures today’s engine recomputes.
Find a deal by name, by street, by asset class or by whoever owns it, then narrow to income or land, to open or closed, and rank the survivors by IRR, NPV or cost basis. The ranking runs on figures recomputed by today's engine rather than on a summary written at some earlier save, and the portfolio totals describe the deals you are looking at rather than the ones you are not.
Sign in the way your security review wants
Two-factor with a trusted-device window that never skips the password.
Two-factor with a twelve-hour trusted-device window, which exempts the code and never the password. A trust cookie on its own is worth nothing. A password reset, an administrator resetting two-factor, or signing out ends it immediately, and a recovery code never earns it, because a recovery code means the authenticator is gone.
Where the data lives
Nothing about your deals is readable in the database
Deal models are encrypted by the application before they are stored, under a key belonging to your organization rather than to the deployment, and so is everything about them: names, asset classes, returns, every saved version, close notes, actuals, photo filenames and captions. The database holds ids, dates and ciphertext.
Open any line for the detail a security review will ask about.
A key per customer
Each organization’s deals are encrypted under a key of its own.
Envelope encryption: each organization has its own data key, which encrypts that organization's deals and is itself wrapped by the master key. A leaked data key exposes one customer rather than all of them. Proven rather than asserted: two organizations, a deal each, neither able to read the other's, checked against the bytes actually on disk.
Uploads too
Photographs are encrypted before they reach storage.
Reference photographs are encrypted with AES-256-GCM under a key derived per object, and stored in object storage that never receives a readable file.
Two-factor authentication
One-time codes, hashed recovery codes, and a switch to require it firm-wide.
Time-based one-time passwords built against the published test vectors, ten recovery codes shown once and stored hashed, replay refused by recording the step a code was accepted on, and a firm-wide requirement an owner can switch on.
Audited, then attacked
Fifteen issues found in a September 2026 audit, all fixed and re-tested from outside.
A security audit of the application in September 2026 found fifteen issues. All fifteen are fixed, and the fixes were then checked from outside: a script that attacks a running copy over HTTP (forged cross-site requests, reused reset links, oversized uploads, timing a sign-in) passes all 34 of its checks.
An export can’t be turned against you
A formula in a tenant’s name stays text, and uploads are opened under limits.
A tenant named =HYPERLINK(…) reaches the workbook as text, never as a formula that runs in a colleague’s spreadsheet. Uploads are checked for archives built to expand, read only so far, and parsed in a separate worker with time and memory limits.
Leaving a firm ends access
The firm keeps the deals; the person who left loses them.
Somebody removed from an organization, or leaving it while colleagues stay, loses the deals they made there, private ones included; the firm keeps them. Closing an account takes the person’s name off everything that stays: deals, history, actuals, the audit log.
A page policy, and sign-in that doesn’t leak
Only the app’s own scripts run, and sign-in gives nothing away.
The app runs under a Content-Security-Policy that allows only its own scripts and its own API. Sign-in takes the same time whether or not an email has an account, and a password reset or two-factor change ends every session, refresh tokens included.
Backups, daily
Every day, as ciphertext. No restore has been rehearsed yet.
The database is backed up every day. Two things worth knowing before you rely on that: no restore has been rehearsed yet, and the dump is ciphertext, so the encryption key has to live somewhere the backup does not.