Security
Last updated: April 27, 2026
SmartTakeoffs handles two things foodservice equipment dealers care about most: their bid documents and their rep relationships. This page explains, in plain language, how we keep that data safe — where it lives, how it's encrypted, who can access it, and the third-party services we rely on. For the legal version, see our Privacy Policy.
At a glance
| Data hosting | U.S.-based cloud providers (AWS & Cloudflare regions) |
| Encryption in transit | TLS 1.2+ for all traffic |
| Encryption at rest | AES-256 at the storage layer; app-level encryption on sensitive fields |
| Tenant isolation | Per-tenant separation enforced at both the auth layer (Clerk) and the database (Postgres row-level security) |
| Authentication | Clerk — SSO-ready, MFA available, session JWTs |
| Customer data & AI training | Your bid documents are never used to train third-party general-purpose AI models |
Where your data lives
Different types of data live in different places, all hosted in the United States by established cloud providers:
- Uploaded bid documents and generated deliverables (PDFs, spreadsheets, quote emails) live in object storage at Backblaze B2, in tenant-isolated paths. Each file is fetched only via signed URLs scoped to the requesting tenant.
- Account and project metadata (project records, rep group mappings, MFR lookups, takeoff line items) live in a managed PostgreSQL database hosted by Supabase. Tenant isolation is enforced by Postgres row-level security (RLS) policies on every tenant-scoped table.
- User identities and sessions are managed by Clerk. Passwords (when used) are hashed and managed by Clerk — we never see them. Clerk also enforces our allowlist for early-access onboarding.
- Application code runs on Railway (backend API + worker queue) and Vercel (frontend + edge runtime).
Encryption
All traffic between your browser, our application, and our backend services uses TLS 1.2 or newer. Object storage and database storage are encrypted at rest using AES-256 by the underlying provider (Backblaze B2, Supabase, and Railway).
On top of that, we apply application-level encryption to sensitive fields in our database (such as outbound email credentials and third-party API keys configured per tenant) using a server-side encryption key that lives only in production environment variables and is never checked into source control or shared between environments.
Tenant isolation
SmartTakeoffs is multi-tenant: many dealers use the same application, but each dealer's data is logically isolated. Isolation is enforced at three layers:
- Authentication— every request is scoped to the signed-in user's tenant. Tenant identity is derived from the Clerk session, not from request bodies or query parameters that could be spoofed.
- Database— every tenant-scoped table has row-level security (RLS) enforcing that a query can only return rows belonging to the requesting tenant. RLS is required on every new tenant table; this is a tested invariant.
- Object storage— uploaded files and generated deliverables are stored under tenant-prefixed paths and accessed via short-lived signed URLs scoped to the requesting user.
Access controls
Within a dealer account, users are assigned roles (estimator or admin). Admins manage the team; estimators run takeoffs and edit their own projects. All edits are captured with version history so you can see who changed what.
Production access at SmartTakeoffs is limited to a small operations team using individually-scoped credentials. Production access is granted on a least-privilege basis and is logged. We never use shared admin accounts. Direct database access in production is reserved for incident response and is audited.
Customer data and AI
SmartTakeoffs uses Anthropic's Claude models to read project manuals and drawings. By default, Anthropic's API does not train on customer inputs or outputs. Your bid documents are sent to the Anthropic API only for the purpose of running your takeoff and are not retained for any other use.
We may use anonymized, aggregated metrics from extraction runs (for example, how often a particular MFR/model combination shows up across the platform) to improve the product. We do not share or sell identifiable customer content.
Backups and recovery
Our PostgreSQL database is automatically backed up by Supabase with point-in-time recovery enabled. Object storage at Backblaze B2 is durably stored across multiple disks and validated against checksums. We periodically rehearse restore-from-backup and disaster-recovery procedures.
Secure development
- All production environment variables (API keys, database URLs, encryption keys) are flagged as Sensitive in our hosting platforms and are never displayed in build logs.
- Source code is hosted in a private repository with branch protection. Production deploys are tied to specific commits and are observable.
- Dependencies are kept current. Automated alerts surface vulnerabilities so we can patch them quickly.
- Form endpoints exposed to the public (such as the early-access request form) are protected by Cloudflare Turnstile to deter automated abuse.
Subprocessors
We rely on a small set of established providers to operate the Service. The current list lives in our Privacy Policy § 6 and is kept current. We notify customers when a material subprocessor change happens.
Compliance and certifications
SmartTakeoffs is an early-stage product and does not currently hold SOC 2, ISO 27001, or HIPAA certifications. We follow the controls described above as a matter of practice, and we're happy to discuss our security posture in detail with prospective customers whose procurement process requires it. Reach out at hello@smarttakeoffs.com.
Reporting a security issue
If you believe you've found a vulnerability or security concern, email hello@smarttakeoffs.com with the details. We'll respond promptly, work with you to verify and reproduce the issue, and remediate as quickly as we can. We ask that researchers act in good faith, avoid degrading the service, and give us a reasonable window to respond before public disclosure.
Incidents
If we become aware of a security incident that affects customer data, we will notify affected dealers without undue delay, share what we know about scope and impact, and describe remediation steps. We maintain an internal runbook for incident response and update it after every event we exercise it on.