Stasora Privacy Policy

Version 0.10, last updated November 7, 2026.

Stasora, Inc. ("Stasora", "we") is a Delaware corporation with its registered office at 131 Continental Dr, Suite 305, Newark, DE 19713. What this policy covers (the "Product"): the Service (the Stasora web app at app.stasora.ai, the Stasora iOS app, and the pages we host for your clients: proposal signing and the client portal) plus the marketing site (stasora.ai). The iOS app has not been released yet; where this policy describes it, that part applies once it is released. Contact: hello@stasora.ai.

1. Scope and roles¶

Who this covers. Contractors and their team members who hold Stasora accounts ("you"), the subcontractors who keep a compliance wallet (§2.8), and the people whose information contractors enter into Stasora: homeowners, property owners, upstream general contractors, subcontractors and vendors ("your clients").

Two roles, one policy.

As your service provider we use client data only to provide, secure and improve the Service for you, on your instructions, and as described here. "Improve" means fixing and evaluating the product, never training a model on your data. Client data is never sold, never shared for advertising, and never used for a purpose of our own beyond that. Client-facing pages (proposal signing, client portal) are viewed by your clients without an account and are part of the service we provide to you.

2. What we collect¶

2.1 Account data (we are the controller)¶

• Email address and full name, from sign-up through Clerk, our authentication provider. Sign-in is by a one-time email code or a password or, on the web, by an emailed sign-in link; Google sign-in and passkeys where available.
• Google sign-in. If you choose Google sign-in, Google sends us only your email address and name, and we use them only to sign you in and label your account. Stasora's use of information received through Google sign-in adheres to the Google API Services User Data Policy, including the Limited Use requirements. We do not receive your Google contacts, calendar, files or anything else.
• A Clerk user ID linking your account to your organization.
• Session tokens, held by Clerk on the web and in the iOS Keychain on the phone. On the phone, the Keychain holds only the Clerk session token; unfinished onboarding answers stay in the app's memory for the session and are not written to the Keychain.

2.2 Organization data¶

Organization name, legal name, license number, business type (general contractor / trade / hybrid), trade tags, tax stance, contact email and contact phone for the business, notification preferences (stored settings only; the product sends no notifications today), plan and entitlements, and, when you connect them, references to your Stripe Connect account and your QuickBooks Online company. Enterprise single-sign-on (SAML) machinery exists in the product; no connection is live today.

2.3 Project and client data (you are the controller; we process it)¶

• Contacts: name, email, phone, contact kind (client, sub, vendor), referral source, and an optional client archetype (homeowner, corporate owner, PM firm).
• Leads (the free CRM): name, company, email, phone, source, status, site address and notes.
• Projects: name, client type, site address, jurisdiction tag, status.
• Documents: estimates, proposals, change orders, invoices, daily logs, lien-waiver and contract templates, uploaded plan sets (PDF/images), and the AI drafts behind them.
• Design visualizations: the site photo your team picks, the finishes chosen for it, the change instruction written from them (§4), and the render that comes back: an AI-generated picture of the home or building with the new finishes, which can show anything the site photo showed. Renders are kept in your organization's private storage (§11).
• Bid invitations: when you invite a subcontractor to bid, the invited company, the invited email, the trade and the scope notes. The sub answers on an account-free page (/itb); their reply (interested, declined or a question), any message, and the name they type are stored with the invitation.
• Signing and portal activity: when a proposal was opened and signed, the signer's typed name and email, the drawn signature (stored as a vector path, not an image file), and a coarse audit note (forwarded IP address and the first token of the browser's user-agent). Portal opens are counted as read receipts.

2.4 Field captures: what the iOS app can actually do¶

The iOS app declares three device permissions: Camera, Photo Library and Microphone. It asks for each one only when you tap a control that needs it, never at launch. The camera is used on three screens: job-site capture (photos into the project record), the compliance wallet (§2.8: photographing a certificate of insurance or a W-9) and the notes reader on an estimate (photographing your own job-walk notes, §4). Camera access is requested only when you first tap "Enable camera" on the capture screen, "Allow the camera" in the wallet or the camera in the notes reader. The system permission text reads "Stasora saves job-site photos into the project record."; it names job-site photos only, although the wallet and the notes reader use the same permission. The photo library is opened only when you tap to choose photos, and its permission text reads "Stasora adds the photos you choose to your project record, and can use one as your company logo." The microphone is used only for dictation (§4), and its permission text reads "Stasora uses the microphone only while you dictate, to type your words into the box you are editing."

Each job-site photo, taken or chosen from the library, is saved to the app's own document directory and queued in an on-device SQLite database so capture works offline; the queue is a staging area on the way to your organization's cloud record. Uploaded photos land in a private Supabase Storage bucket readable only by your organization's members under row-level security. We do not remove camera metadata (EXIF) from a job-site photo before upload: each file is stored as the camera or the photo picker hands it to the app. The iOS app adds no location to a photo and has no permission to read your location. A photo chosen from your library, uploaded from a computer, or taken through a phone's web browser can keep whatever metadata that device or file already carries, which can include when it was taken, the camera model and, if that device recorded it, where. That metadata stays with the stored file in your organization's private storage. It is removed from the copy of a photo we send to an image model for a design visualization (§4), from the copy of a job-site photo we send to Anthropic when someone on your team picks it to draft an estimate from (§4), and from every copy of a picture attached to a proposal (a photo or an approved render) that your client opens through a signing link or a portal link: those copies leave our server without location, camera or owner details. A photo of notes pages you send to be read (§4) and a company logo have their hidden file data removed before they are stored. Your company logo is stored at a public web address, so it can print on your documents and on the pages your clients open. A capture row records the uploader, date, optional phase tag and an optional narration-language label (text, not a recording).

2.5 Device and usage data¶

• Device attribution. When you edit a shared record, we store a coarse device label ("iPhone", "iPad", "Android" or "Web") with the change, so both platforms can show "last edited on iPhone · 12 minutes ago." This is deliberately not a fingerprint: no device ID, install ID or hardware model is stored with the change.
• Activity ledger. Every meaningful action (approve, edit, sign, upload, assist-session start/end, API key created or revoked, wallet shared or revoked) is written to an organization-scoped activity_events table with actor, subject and timestamp, readable and exportable by your organization.
• AI run ledger. Every AI call records the prompt version, a content-hash reference to its inputs (a short fingerprint that identifies which inputs were used, not the inputs themselves), who ran the call, any assist session it ran under (§6), model role, model, approval state, approver and cost: what ran, not a copy of your prompt text.
• API key use. For each API key you create (§5), the time it was last used and a request counter for the rate limit.
• Server logs. Our hosting provider, Vercel, logs each request to the web app: its method, path and query string, time, status code, host, the browser's user-agent and the region that served it, and the messages our server code writes. Vercel also processes your IP address to route requests and protect the service. Vercel keeps these logs for between 1 hour and 3 days, depending on the hosting plan, or 30 days if its Observability Plus add-on is turned on.
• Product analytics (PostHog). On the marketing site, PostHog records page views without a cookie and without writing anything to your browser's storage. These events are pseudonymous, not anonymous: they carry no name or email, and they are keyed to a random visitor ID that our page keeps in our own cookie, stasora_vid (§9), and hands to PostHog, so that a first visit can be linked to a later sign-up. The web addresses in these events reach PostHog with anything after "#" removed and with their query string cut down to the campaign tags (utm_source, utm_medium, utm_campaign, utm_term and utm_content) and Google's click ID (gclid). In the web app, after you sign in, PostHog records which screens your account opens, tied to your Clerk user ID, together with the first visit that led to your sign-up (its referrer, landing page, campaign tags and device class) and that visit's visitor ID. Each screen is recorded as its web address with the query string and anything after "#" removed, so it can carry a record's ID but never your search text or a name you typed. To remember that this browser has already identified you to PostHog, the web app keeps your Clerk user ID in your browser's local storage (stasora-posthog-identified, §9). The web app's analytics, and the iOS sign-in report below, begin only after the notice §14 promises has been given to the users who hold the Owner role; they run only when the deployment's analytics switch is on, and they load on no client-facing page (proposal signing, the client portal, a subcontractor's bid-invitation or account-claim page). Your IP address. PostHog receives the IP address of the device that sends each event, as any web service does, and derives from it an approximate location (country, region and city), which it keeps with the event for the period in §7. We do not store your IP address from analytics, and PostHog is set to discard the address itself once the location is derived. The iOS sign-in report is sent from our server, so no location is derived for it. No session is recorded or replayed for a customer workspace; session replay, with typed input masked, runs only in Stasora's own and demo workspaces. In the iOS app, signing in tells PostHog, from our server, your Clerk user ID and the first visit that led to your sign-up when one is on record (the same referrer, landing page, campaign tags and device class, set once); the iOS app itself still carries no analytics, tracking pixel, session-replay or advertising SDK, it sends nothing to PostHog directly, and no session is ever recorded or replayed on the phone. No advertising SDK or tracking pixel runs anywhere in the Product.

2.6 Payment data: what Stripe holds vs. what we hold¶

Your clients paying you. Payments run on Stripe Connect with Stripe-hosted onboarding and Stripe-hosted checkout pages. Payment card and bank details never touch Stasora's servers. When you set up payouts we send Stripe your organization's display name, your email and our internal organization ID. When you request payment we send Stripe the invoice amount, invoice number and a client-facing description. Stripe returns account status, capabilities and payment events, which we store against the invoice.

You paying us. When you buy a plan or a service from Stasora, checkout is a Stripe-hosted page in Stasora's own Stripe account. We send Stripe your organization's name, your email, our internal organization ID and the item purchased; Stripe holds your card and returns the payment result, which we record against your organization.

2.7 Accounting data¶

If you connect QuickBooks Online, invoices and recorded payments sync one-way from Stasora to QuickBooks (halting on conflict rather than overwriting), and contacts sync two-way limited to name, email and phone. Internal cost data (unit costs, crew rates, markups) is structurally excluded from anything that crosses. We hold the OAuth tokens Intuit issues; we never hold your Intuit password.

2.8 Subcontractor compliance wallet¶

If you are a subcontractor, the iOS app lets you photograph two documents and keep them in a wallet under your organization's settings:

• your certificate of insurance (COI), with the carrier, policy number and expiry date you type in; and
• your W-9. A W-9 carries a taxpayer identification number, which for a sole proprietor is usually a Social Security number. This is the one place in the Product that holds a government ID number. We store the photo you take; we do not read or extract the number from it.

Where it lives. The photo is stored in a private compliance storage bucket under your own organization's path. Only your organization can read, add or replace its documents. Replacing a document keeps the earlier file, because a certificate that covered a job is part of the record of what a contractor was shown at the time.

Who sees it. Nobody, until you share it. You can share your wallet only with a contractor who has invited you to a job. That contractor then sees these two documents and nothing else in your account: not your other jobs, prices or other contractors. You can revoke a share at any time; opening and closing a share is written to both organizations' activity ledgers. Client-facing pages and field roles cannot read the wallet. We use these documents only to show them to the contractors you authorize; we never sell them, never share them with anyone else, and never use them for any other purpose.

How long. For as long as your organization exists; the wallet is deleted with your organization under §7.

2.9 Waitlist on stasora.ai (we are the controller)¶

If you join the waitlist on the marketing site, we keep what the form asks for and nothing more:

• your email address; and
• your trade, your crew size (a band, such as "2 to 5"), the tools you use today (from a fixed list), and the monthly price band you say you would pay.

The form does not ask for your name, phone number or company, and it sets no cookie. Each entry is also tagged with where it came from (the marketing site) and when.

Why we keep it. To decide whom to invite first and what to build next. We read the answers ourselves; no AI model is run over them.

What we send you. Joining sends no email. When your spot opens, a person at Stasora sends you one email from hello@stasora.ai. Nothing is sent to you automatically, and we send no marketing email.

Who sees it. Stasora staff only, through our staff-only operator screen. No contractor workspace can read it, and it is never sold or shared for advertising. It is not linked to a Stasora account if you later open one.

Abuse limits. To stop automated sign-ups, the server counts recent attempts per network address and per email address, in memory, for up to an hour. The network address is not stored with your answers. Hosting logs are covered by §2.5.

How long. Until you are invited or 18 months after you sign up, whichever comes first; we delete it sooner whenever you ask at privacy@stasora.ai. Signing up again with the same address keeps your first answers; to change them, write to us.

3. How we use information¶

• Operate the service: the shared project spine across web and iOS, offline capture and sync, document rendering, client signing and portal pages, the compliance wallet and the bid-invitation pages.
• AI features with human approval: AI drafts estimates, proposals, change orders, invoices, follow-ups, takeoffs and design visualization previews; a named person on your team approves before anything becomes client-facing or financial. Nothing auto-sends; the product has no email or SMS sending capability of its own today. Pay links and signing links are copied by you and sent however you communicate with your client.
• Background jobs (via Inngest): scope-creep candidates when a daily log is approved, once-daily collections follow-up drafts on aged invoices, and activation-metric events. All produce drafts or internal rows; none contacts a client.
• Support via assist sessions: see §6.
• Billing and account administration: plan, entitlements, spend caps, suspension.
• Security and integrity: tenant isolation, request signature verification, abuse limits, the activity ledger.
• References and case studies: only with your written opt-in, and only the name, logo and story you approve.
• Legal obligations and enforcing our Terms.

4. AI processing¶

• All AI calls are made server-side: to the Anthropic API; for design visualization renders, to OpenAI or, when OpenAI cannot render, to Google's Gemini API (below); and for dictation, to OpenAI's speech-to-text model (the next sentences). The Anthropic client throws if constructed in a browser; no model key ships to the client. Dictation (speech to text). When someone taps the microphone in a text box, the app records audio until they stop it, for at most 10 minutes, and our server sends that recording to OpenAI's speech-to-text model with a short description of a contractor's job notes and spelling hints: your organization's approved shorthand terms and, when the box belongs to a project, the project's name and its client's name. The text that comes back is placed in the box, and it is saved only if and when the box is saved. We do not store the recording; the AI run ledger keeps its cost, the model and a fingerprint of the file (a hash), never the audio or the words. On the iPhone, the app deletes its temporary copy of the recording after each attempt. The microphone is shown only when dictation is switched on for your workspace. OpenAI's published data controls state that its transcription endpoint's data is not used for training, and list no abuse-monitoring retention and no application-state retention for it.
• Inputs sent for a given feature are the inputs that feature needs: for example, the project's signed scope and daily-log text for scope detection. The only images and files sent to a model are plan-set pages you upload for takeoff; pages of your own job-walk notes (photos or PDFs) that you send to be read into a draft estimate, a photo's hidden file data removed first; a PDF worksheet you import and ask us to read; up to six job-site photos of a project that someone on your team picks to draft an estimate from, sent to Anthropic with their hidden file data removed first, with every quantity read from a photo marked for a person to check; and the one site photo your team picks for a design visualization (below). Capture notes (text) are sent for translation; no other jobsite photo is sent to any model. If that changes we will update this section.
• Every call is logged in the AI run ledger (§2.5), is subject to a kill switch and per-organization spend caps, and its output is stored as a draft until a named human approves it.
• Stasora does not use your data, your clients' data, or AI outputs to train models of its own.
• Anthropic's handling of API inputs and outputs is governed by Anthropic's Commercial Terms of Service (https://www.anthropic.com/legal/commercial-terms, effective June 17, 2025).
• Design visualization renders. When someone on your team asks for a design visualization (a preview of new colors or materials on a home or building, outside or inside, such as paint, siding, flooring or a kitchen backsplash), we send an image model two things: the site photo the contractor provides, and the change instruction, such as a paint color or a flooring material, which our AI writes from the finishes, surface names and photo caption your team entered. Before the photo is sent, our server removes the hidden data stored in the file (§2.4): its EXIF data (including any GPS location and the camera's make, model and serial number), XMP, IPTC, comments and embedded text. Only what the picture needs to display correctly is kept, such as its color profile and its orientation, and a photo our server cannot read is refused and not sent at all. Only that hidden file data is removed: the picture itself is sent as it is, and a site photo can still show the outside or the inside of a home or building and anything visible in it, such as people, belongings, papers, screens, vehicles, a house number or neighboring homes. We send it to OpenAI first. Only when OpenAI cannot render it (OpenAI is not set up for us or does not accept our key, is down or busy, or does not answer) do we send the same photo and instruction to Google through the Gemini API; we never send it to Google after OpenAI declines to render it. The picture that comes back is kept in your organization's private storage, labeled as generated by AI, and your client sees it only after a named person on your team approves it.
• What OpenAI does with a render request (its standard API terms). OpenAI does not use data sent to its API to train or improve its models unless the customer opts in to share it, and we do not opt in. OpenAI keeps abuse-monitoring logs, which can contain what we send, the picture it returns and metadata OpenAI derives from them, such as classifier outputs, for up to 30 days, or longer where the law requires it or where it is reasonably necessary to protect its services or anyone else from harm. Apart from the scan below, OpenAI lists no other retention for its image edit service. OpenAI scans every image sent to its image endpoints, ours included, for child sexual abuse material when it arrives, and keeps an image its classifier flags for manual review. OpenAI's published data controls name no default location for API data; their example of a request sent without a chosen region, as ours are, marks it as having no processing constraint, and keeping data in a chosen region is an option for eligible customers.
• Standard terms only. We use OpenAI on the standard terms above. OpenAI offers zero data retention only with its own prior approval, and we do not have it, so the abuse-monitoring logs above apply to every render request we send OpenAI.
• What Google does with a render request (its standard terms for paid use). We use the Gemini API only as Google's paid service; on its free service, Google uses what is sent to improve its products. On the paid service, Google does not use prompts, including images sent with them, or responses to improve its products. It logs prompts and responses for a limited period, only to detect and prevent violations of its Prohibited Use Policy and for any required legal or regulatory disclosures. Its abuse-monitoring page says it keeps prompts, the context sent with them and the responses for 55 days, that authorized Google employees may review content its safety systems flag, and that a project that consistently exhibits suspicious activity may be flagged for manual review by authorized Google personnel. Google says this data may be stored transiently or cached in any country where Google or its agents maintain facilities.

5. Sharing and sub-processors¶

We share personal information only with the sub-processors below, each acting on our instructions; with your own clients when you publish a signing link or portal link; with the contractors a subcontractor authorizes through the compliance wallet (§2.8); and with the holders of API keys you create (below). This is the same sub-processor list as in our Terms of Service; we update it before adding a provider that will process your data.

Marketing site only. The pages at stasora.ai load their typefaces from Google Fonts (fonts.googleapis.com / fonts.gstatic.com), which means your IP address reaches Google when a marketing page loads. Nothing about your account is involved, and the web app and the iOS app do not use Google Fonts. The marketing site also counts page views in aggregate through Vercel Web Analytics and records page events through PostHog (§2.5), both without a cookie; the one cookie it sets is our own stasora_vid (§9).

Integrations you authorize. In the web app's Settings, a user who holds the Owner role can create an API key. Whoever holds that key (an outside tool, a bookkeeping system, or an AI agent you connect; the MCP server runs on the same keys) can read your organization's projects, invoices and their payment status. A key is read-only (there is no write endpoint), scoped to your organization only, never sees cost-side data, and is not a sign-in. We store only a hashed fingerprint of the secret, never the secret itself. You can revoke a key at any time in Settings → API & MCP; creating and revoking a key is written to your activity ledger. Data a key holder reads is shared on your instruction, and what they do with it is governed by your arrangement with them, not by this policy.

We do not sell personal information and do not share it for cross-context behavioral advertising. We may disclose information when required by law, to protect rights and safety, or in a merger or acquisition (with notice).

6. Assist sessions: when Stasora staff enter your workspace¶

Stasora staff can enter your workspace only through an assist session:

• A staff member must state a reason and choose a level: look or fix. The level records why the session was opened; it does not limit what the session can reach.
• The session is a temporary membership in your organization that holds your organization's own Owner role: in plain terms, a temporary seat on your team with full read and write access to everything in your workspace, exactly as a user who holds the Owner role has, including your cost-side figures (unit costs, crew rates, markups and margins). Whatever that role can see or change, the staff member can see or change during the session. It is not a login as you: the staff member joins your team as themselves, under their own name.
• A session may be started by Stasora staff without your prior approval; when it is, the open session is visible on Roles & permissions and in your activity ledger. Where one of your Owner-role users asked for the session first, the record names who asked.
• A staff member can hold only one live session at a time, and a session is refused when that staff member already holds a membership in your organization.
• Every session is time-boxed to at most 8 hours and torn down by the clock whether or not anyone ends it. A live seat cannot be removed mid-session; the clock restores your control.
• Start and end are written to your activity ledger and to Stasora's own internal record of staff actions, and the open session is named on your Roles & permissions screen in the web app while it is live: who, why, what the level can reach, and when it ends.
• Not yet built (recorded as owed): a banner on every screen, a notice at the moment a session starts, and the same line in the iOS app. Until then, check Roles & permissions on the web.

7. Retention and deletion¶

• Account and organization data: retained for the life of the account and for 10 years after account closure, then deleted.
• Project and client data (contacts, leads, projects, documents, invoices, bid invitations, signing records, design visualizations and their renders): retained for the life of the account and for 10 years after account closure, then deleted.
• Jobsite evidence (photos, captures, daily logs): retained for 10 years after the project closes, then deleted. This rule applies whether or not your account is still open.
• Compliance wallet (§2.8): for the life of the subcontractor's organization, then deleted with it under the account rule above.
• Waitlist entries (§2.9): until you are invited or 18 months after you sign up, whichever comes first, or sooner when you ask us to remove you.
• Sign-in and session records: held by Clerk and kept under the account rule above. Under its terms with us, Clerk deletes what it still holds within 90 days after our agreement with it ends.
• Product analytics (§2.5): held by PostHog for the period our PostHog plan sets, as PostHog publishes it: events for 1 year on its free plan and 7 years on its paid plans; session replays, which run only in Stasora's own and demo workspaces, for the period set in PostHog's replay settings, at most 30 days on its free plan and 90 days on its pay-as-you-go plan.
• Legal holds and backups: we keep data past these periods only where the law, a litigation hold, or tax and payment record-keeping requires it, and then only that data and only for as long as required. Deleted data can remain in our database provider's backups until those backups expire, at most 30 days later.
• Stripe and Intuit records: governed by those providers once transmitted.
• On-device queue: photos remain on the phone until uploaded; the queue is a staging area, not a destination.
• Deleting your organization is a written request to privacy@stasora.ai until self-serve deletion ships.

8. Your rights and choices¶

• Access and export. A full export of your organization's data is available on written request now: email support@stasora.ai and we deliver it within 10 business days of your written request. The export covers everything: your records as CSV and JSON, your files and photos in their original formats, signed documents as PDF, your activity ledger, AI drafts and e-sign audit notes. Stasora intends to ship self-serve export before billing turns on; the same scope applies to self-serve export when it ships.
• Correction. Edit records directly in the web or iOS app.
• Deletion. Written request to privacy@stasora.ai, subject to §7 and legal holds.
• Marketing. We send no marketing email from the product today; transactional sign-in codes come from Clerk.
• Requests from your clients: one rule, used here and in §10. A homeowner or an upstream general contractor whose information a contractor entered may send a request either to the contractor who holds their data or to privacy@stasora.ai. Because you have no Stasora account, we verify you by matching the email address on the document you signed or were sent, plus the contractor's confirmation. We then assist the contractor in answering within the time the law allows. We will not delete a contractor's records at a client's request without the contractor's instruction unless the law requires it.
• What the signing page tells you. The proposal and change-order signing pages name Stasora as their operator and link to this policy and our Terms. That an IP address and a short browser note are recorded at signature is disclosed here (§2.3), not on the signing page.
• Cookies and local storage. See §9. The theme preference, the activation log, unfinished onboarding answers and the analytics note can be cleared in your browser.

9. Cookies and similar technologies¶

First-party cookies and storage set by Stasora:

Clerk sets the cookies that keep you signed in: __session, a signed sign-in token on app.stasora.ai that lasts 60 seconds, and __client, on Clerk's sign-in domain clerk.stasora.ai, whose lifetime your browser limits. If Vercel's firewall asks a browser to pass a security check, it keeps a challenge session in that browser for 1 hour. We set no advertising or analytics cookies and honor no ad-tracking because we do none: PostHog runs without a cookie on the marketing site and in the web app and writes nothing to your browser's storage itself; the web app's own analytics note, stasora-posthog-identified (above), is the one storage entry analytics use, and the iOS app sends PostHog nothing itself: its sign-in is reported from our server (§2.5). The marketing site sets exactly one first-party cookie of its own, stasora_vid (above), and no analytics or advertising cookie; see §5 for Google Fonts.

10. California notice (CCPA/CPRA)¶

Stasora does not meet the thresholds that bring a business under the California Consumer Privacy Act (CCPA) today. We give this notice anyway, and we honor requests to access, delete and correct personal information from everyone, wherever they live.

• Categories collected (12 months): identifiers (name, email, phone, account IDs, the random visitor ID of the stasora_vid cookie, and the IP address PostHog receives with each analytics event, §2.5); commercial information (estimates, invoices, payments, items you buy from us); internet/electronic activity (activity ledger, coarse device label, sign-in events, signing audit note, API key use, product analytics events and the marketing site's first-visit record, §2.5); audio/visual (jobsite photos and the design visualization renders made from them; photos of insurance certificates and W-9s in the compliance wallet); professional information (trade, business type, contractor license number, insurance carrier and policy details); sensitive personal information (see below); approximate location only (country, region and city), which PostHog derives from the IP address of the device that sends an analytics event (§2.5). Not collected: precise geolocation (site addresses are project data entered by the contractor; a photo uploaded from a computer can carry location metadata of its own, §2.4), inferences for profiling.
• Sources: you, your team, subcontractors who keep a compliance wallet or answer a bid invitation, your clients when they sign or open a portal, Stripe and Intuit when connected, Google if you choose Google sign-in.
• Purposes: §3.
• Sold or shared: No. We do not sell personal information and do not share it for cross-context behavioral advertising, and have not in the preceding 12 months.
• Service-provider role: for client data we act as your service provider under a written contract (our Terms) and use the data only to perform the service.
• Sensitive personal information: collected in one place. A subcontractor's W-9 in the compliance wallet (§2.8) carries a taxpayer identification number (for a sole proprietor, usually a Social Security number). We use it only to show the document to the contractors the subcontractor authorizes; it is never sold, never shared otherwise, never used to infer anything about anyone, and is deleted with the wallet. Because we already limit its use to that purpose, a request to limit use changes nothing, and we honor it. Card and bank data are held by Stripe, not by us.
• Your rights: know, delete, correct, portability, limit use of sensitive personal information, and non-discrimination. Account holders exercise them at privacy@stasora.ai; we verify an account holder by matching the account email. Homeowners and upstream general contractors follow the rule in §8: write to the contractor who holds your data or to privacy@stasora.ai; we verify you by matching the email on the signed or shared document plus the contractor's confirmation, and we assist the contractor in answering. Authorized agents may submit requests with written permission.

11. Security¶

• Tenant isolation: every organization-scoped table has row-level security; the tenant claim is minted by Clerk and verified inside Postgres, never trusted from a header. In plain terms: on every query the database works out which organization you belong to from your signed sign-in token, and never from something a request merely says about itself.
• Private storage: photo, plan, design visualization render and compliance buckets are private; files are served through short-lived signed URLs to members of your organization (or, for the wallet, to a contractor with a live share). A render a named person on your team approved reaches your client only through your portal link: our server reads the picture and passes it on, and no link to the stored file leaves our servers.
• Cost/price firewall: internal cost data lives in fields that client-facing renderers structurally cannot reach, checked by automated tests. The same firewall applies to API keys and the MCP server.
• Client-facing links: signing and portal links are 256-bit random capability tokens, verified inside the database, scoped to a single document or project, revocable, and closed 30 days after they are sent. In plain terms: the link contains a long random code that is practically impossible to guess; the code is the key, it opens only the one document or project it was made for, and you can cancel it at any time; after 30 days it closes by itself.
• Integrations you authorize: API keys are scoped to one organization, read-only, and stored only as a hashed fingerprint; a database user cannot read the secret back; revoked keys stop working immediately and stay on record as revoked. Every key is rate-limited.
• Encryption: TLS in transit; at rest, our database and file storage provider (Supabase) encrypts all customer data with AES-256.
• Secrets and webhooks: no API keys in client code or the repository; Stripe and Inngest webhooks are signature-verified before any write.
• On-device: session tokens in the iOS Keychain; queued captures in the app's sandboxed storage.
• No method of transmission or storage is completely secure and we cannot guarantee absolute security. We will notify you of a breach affecting your data as the law requires.

12. Children¶

Stasora is a business tool for contractors and is not directed to anyone under 18. We do not knowingly collect personal information from children. If you believe a child's information has been entered, contact privacy@stasora.ai and we will work with the controlling contractor to remove it.

13. Cross-border transfers¶

Stasora is built for contractors in the United States, and your information is stored in the United States: the database and file storage in Northern California, the web app's functions in Washington, D.C., and background jobs in Ohio and Virginia. Some providers in §5 may process it elsewhere: Anthropic may run an AI request in Europe, Asia or Australia; OpenAI's published data controls name no default location for a design visualization or dictation request, and their example of a request sent without a chosen region, as ours are, marks it as having no processing constraint; Google may store a Gemini API request transiently or cache it in any country where Google or its agents maintain facilities; and Stripe, Intuit, Clerk and Google (sign-in) may process data in the other countries where they operate, each under its own terms. If you use Stasora from outside the United States, your information is transferred to the United States.

14. Changes to this policy¶

We will post changes here with a new version and date. Material changes will be announced in the app or by email from legal@stasora.ai to the users who hold the Owner role, before they take effect.

15. Contact¶

Stasora, Inc. · 131 Continental Dr, Suite 305, Newark, DE 19713 (registered office) · Privacy contact: David Campos, Founder and Chief Executive Officer, privacy@stasora.ai for data requests; legal notices to legal@stasora.ai.