Privacy Policy

This policy explains what personal information UpScale.build collects, why we collect it, who we share it with, which countries it goes to, and how you can see, correct or delete it. It applies to the website at upscale.build, the UpScale.build app for iPhone and iPad, and the emails and notifications we send. It is written to meet the Australian Privacy Principles in the Privacy Act 1988 (Cth).

We have tried to write it in plain English. If anything is unclear, email hello@upscale.build and we will explain.

1. Who we are

UpScale.build is operated by the Australian business trading as UpScale.build. In this policy "we", "us" and "UpScale" mean that entity.

Privacy contact: hello@upscale.build.

2. Two kinds of information

We hold two kinds of information, and the difference matters for what you can ask us to do.

1. Information about you that we collect for our own purposes — your account, billing, the emails we send you, how the website is used, and support. We decide how this is handled and this policy governs it.
2. Project data your organisation enters — budgets, contracts, claims, invoices, site diaries, defects, tenders, and the people named in them. We hold this on behalf of the organisation that entered it. The organisation controls who can see it through the roles and permissions it sets, and it is responsible for having the right to record other people’s information (see section 4).

3. Information we collect

3.1 When you create an account

When you create an account we collect your name, email address and organisation details, and optionally your time zone. Your password is stored by our authentication provider (Supabase) in hashed form, not as plain text. If you use the mobile app, it records your device’s time zone once, only if you have not already chosen one.

If you sign in with Google, Google gives us your Google account ID, email address, name and a link to your profile picture. If you sign in with Apple, Apple gives us an Apple user ID, your email address (or a Hide My Email relay address if you choose that), and your name the first time only. The name and picture link are copied to your profile.

If you arrived at the website from an advertisement or campaign link, the campaign details described in section 8 are attached to your sign-up.

To create an organisation on the website we need your name, email address and organisation name. In the app the name is optional; if you leave it blank, the part of your email address before the @ is used as your display name (including in the sign-up record we pass to HubSpot, section 6) until you change it in Settings. Accounts created by invitation need only your name, your email address and a password, or a Google or Apple sign-in.

3.2 Project data you enter

When you use the platform, we collect the project data you enter — budgets, contracts, claims, variations, invoices, site diary entries, defects, RFIs, meetings, tenders, feasibility scenarios, and the addresses of the projects and companies you record. Much of this names other people: contractors, consultants, suppliers, client contacts, property purchasers, sales agents, site visitors and meeting attendees. Section 4 explains how we treat their information.

3.3 The mobile app

The UpScale.build mobile app collects the same project data, and because the work happens on site it can also capture:

• Photographs and video (with sound) you take with the camera or choose from your photo library — for example site diary photos, defect photos, progress-claim evidence, sales-update photos, floor plans, and photographs of invoices and dockets. Photos captured or chosen in the app are re-encoded before upload, which removes the information a camera embeds in the file (the time it was taken, the device, and the location if your camera records it). Videos, and any files uploaded from the website, are stored exactly as produced, so any information embedded in those files stays with them and is visible to anyone who can open them.
• Audio recordings you choose to make as site diary walkthrough notes (up to ten minutes each).
• Documents you attach, including drawings, programmes and supplier invoices.
• A push notification token issued by Apple, if you allow notifications, so we can tell your device when something on your project needs you.

The camera and microphone are used only when you start one of those actions, and iOS asks your permission before the first use of each. Choosing from your photo library uses Apple’s picker, so the app never has access to your library — it receives only the photos or videos you select. Nothing is captured in the background.

The mobile app contains no advertising software and no third-party crash-reporting software. It sends product-usage analytics to PostHog (section 6). An event records which screen was opened or which action was completed — for example that a site diary entry was saved with two photos, or that a defect was closed — together with a random installation identifier and the app and iOS versions and, once you are signed in, your account ID, your organisation ID and your role in it. It never carries the content of what you record: no project names, names of people, addresses, amounts, notes, photos or documents. Events wait on your device until they can be sent, so one recorded without a signal is sent later, and the app keeps no more than the latest 500.

Crash and hang diagnostics. If the app crashes, hangs, or is stopped by iOS for using too much processor time or writing too much to disk, Apple’s MetricKit framework (part of iOS, not a third-party kit) hands the app a diagnostic report the next time it opens. The app stores that report on the device and sends it to our API, and we forward it to Sentry (section 6), our error-monitoring provider. A report contains the type of failure, the code that was running at the time (a stack trace), the app and iOS versions, the device model, the time the report was captured, and the few device details Apple includes in every report: the region format your phone is set to (for example “AU”), whether Low Power Mode was on, whether the build came from TestFlight, the processor architecture, and the app’s bundle identifier and process number. It does not contain your project data, your name, your email address, or any account or device identifier. It is sent under your signed-in session; before our server passes it to Sentry it removes the sign-in token and any cookies from the request record Sentry keeps alongside it, so — unlike a server error report (section 3.6) — that record never contains your session token, and the copy in Sentry is tagged with your organisation ID only. Reports wait on the device until they can be sent (the newest twenty are kept) and are sent only while you are signed in; in demo mode nothing is sent. This does not depend on the “Share With App Developers” setting on your iPhone or iPad: MetricKit provides these reports to the app whether that setting is on or off.

Separately, if your iPhone or iPad is set to share diagnostics with app developers (or you use a TestFlight build), Apple also sends us crash reports for the app through App Store Connect; these contain device and crash details, not your project data. When the app opens a page of our website in its built-in browser (for example the full feasibility view), the website’s analytics and advertising measurement described in section 8 run there as they do on the website, and that browser holds the website’s cookies (section 8). The app’s sign-in screens load a Cloudflare bot check (section 3.6).

3.4 Where your files are kept

Photos, video, audio, documents, tender submissions and copies of invoice emails are written to your organisation’s own Dropbox, Google Drive or Microsoft OneDrive account, in a folder called "UpScale Projects", once a Super Admin connects one (section 11). Our database keeps the file name, size, type, a link, who uploaded it and when, the length of audio recordings, a fingerprint (hash) of invoice files, and the folder identifiers in your drive — never the file content itself. Files are served back through links that check your access. Organisation logos are stored by us and are publicly readable. Some files uploaded before we moved to customer-connected storage are held in our own storage (section 6) and are served only through access-checked, short-lived links.

3.5 Emails sent to a project’s invoice address

An internal user can give a project an email address (the project’s name is part of the address) so suppliers can email invoices to it. When an email arrives we record the sender’s email address and display name, the reply-to address, the date, the names and lengths of the email headers (not their values), the results of the sender’s SPF, DKIM and DMARC checks, and for each attachment its file name, type, size and a fingerprint. We do not store the subject, the message body or the attachment contents in our database. A copy of the whole email, including attachments, is written to your organisation’s connected cloud storage. If no cloud storage is connected, we keep no copy of the email content. Attachments are not virus-scanned by us. Our email provider (Postmark) also holds a copy for its retention period (section 12).

3.6 Technical and security information

• Sign-in records. Our authentication provider records the IP address and browser or app details of each signed-in session for as long as the session exists, and keeps its own service logs of sign-in events for about seven days.
• Bot protection. Sign-in, sign-up, password-reset and account-security screens on the website and in the app run a Cloudflare Turnstile check. Cloudflare receives your IP address, TLS fingerprint, browser user-agent and our site key, solely to detect bots. For sign-in, sign-up and password reset our authentication provider then sends the check result and your IP address to Cloudflare to verify it; on the account-security screens (change email, change password) the check is relayed through our server, so the address Cloudflare sees there is our server’s rather than yours.
• Rate limits. To stop abuse, we count requests to the public share pages (client portal, meeting minutes and feasibility share links) by IP address, and requests to some signed-in features by account. These counters are stored in our database. When a limit is exceeded, a warning naming the counter (which contains the IP address or account identifier) is written to our logs and error monitor.
• Hosting logs. Our hosting provider (Vercel) keeps a short-lived request log — currently about one hour — recording the page or API address requested, the time, the response status, your browser’s user-agent and your IP address. On the client portal, meeting-minutes and feasibility share pages the address recorded includes the share link.
• Error reports. Errors on the website, server errors on requests the app makes to our API, and the app’s crash and hang diagnostics (section 3.3) are reported to Sentry. A report can include the page or API address, browser or app details, recent console messages and, for server errors, the request details including headers and cookies — which can include your sign-in session token (and, for the app, its sign-in token header). Sentry’s server-side scrubbing, which Sentry enables by default, removes values in fields named like passwords, tokens, auth or bearer before storage. Before a website error or performance diagnostic is sent, our application also removes share-link and authentication credentials from page addresses, messages, stack traces and related diagnostic fields. Sentry records a masked session replay (text, form inputs and images hidden) of about one in a hundred sessions and of any session in which an error occurs; a replay is not started on a page whose address carries a credential, and an active replay is stopped without sending its pending segment when the browser enters one.
• Web hand-off. When you open the website from the app, we record that a one-time sign-in link was issued (your account ID, the time and the destination page).

3.7 Website usage and campaign information

On the website we use Google Analytics and the Meta Pixel to understand how the website and product are used and to measure advertising. On ordinary pages Google Analytics receives the address and title of each page you view, a browser identifier stored in a cookie, and product events such as signing up, completing onboarding and creating a project. On ordinary pages the Meta Pixel receives the address of each page, the page that referred you, a browser identifier and one event when you sign up. Both also receive your IP address and browser details with every request. These tools are paused whenever the current address carries a share-link or authentication credential, including when the credential is nested inside a redirect parameter or appears after the #. On other signed-in pages the address includes internal record identifiers (for example a project or claim ID) but not the record’s content; a payment session reference can also appear in an ordinary billing address. One feasibility event carries a forecast profit figure. If you arrive from a campaign link, the campaign identifiers in the link are stored in your browser for 90 days and attached to your sign-up. Section 8 lists the exact cookies and storage, and how to opt out.

3.8 Records the service creates as you use it

• An activity history for each project (who did what and when).
• A record of each tender document download by a tenderer (who, which company, which file, when) for probity.
• The most recent time a meeting-minutes recipient opened the shared minutes (updated on each view), and a view count and last-view time for feasibility share links.
• Which AI feature you used, when, by which account and organisation, and which model — not the content sent or returned, except that Ask UpScale questions and answers and development control plan summaries are kept as described in section 7.
• Your notification preferences, and the invitations, share links and access grants you create.

3.9 Anonymity

You can read a feasibility share link without an account or any identification, although the per-address request counter in section 3.6 applies. Everything else requires an account, because the service is built around who is allowed to see which project.

4. People who are not our customers

Much of the personal information in the service is about people who do not hold an account with us. This section is for them, and for the organisations that record their details.

Team members and invited people. An internal user can invite colleagues, and clients, consultants and contractors, to a project. The inviter supplies your email address and may supply your name, company and discipline. If you already have an account, we record the offered access and email you a link to accept it; that offer lapses after 24 hours if you do not accept it. If you do not have an account, we create one for your email address straight away (with the name, company and discipline the inviter supplied, a membership record for the organisation or project and, for project invitations, a company record in the inviting organisation’s register) and email you a link to set a password, naming the person and organisation who invited you. That pending account and its membership do not expire automatically; they stay until you accept or the inviter cancels the invitation — tell us if you want it removed. We record who invited you and when.

Tenderers. A tender lead invites tenderers by supplying an email address, company name and contact name. We create a sign-in for that address (marked as a contractor account, with the name supplied), add the company to the inviting organisation’s company register if it is not already there, record the contact email against the tender, and email the tenderer when the tender is issued or when they are added to an open tender, when a notice is posted, when the result is decided and if the tender is cancelled. Tenderers submit files (stored in the inviting organisation’s cloud storage), a bid amount and notes, and responses to clarifications. Every package or addendum download is receipted. Bid prices are sealed until the tender lead reveals them. A tenderer sees only the tender, its notices and their own submission — never other bidders. The tender portal is part of the website, so the analytics and Meta Pixel in section 8 run on it.

Meeting-minutes recipients. An internal user can share meeting minutes with an email address that has no account. We store that address and a link token, email the link, and record the most recent time the minutes were opened (each time you open them, that time is updated and is visible to the person who shared them). To open the link you must sign in with an account whose confirmed email address matches the one the minutes were shared with. If the address has no account, we also create a pending sign-in for it (an account with no password) and include a link to set a password, because opening minutes requires signing in. That pending account remains until it is accepted or an administrator removes the share.

Client portal readers. A client portal link identifies a project, not a person. To open it you must sign in (if you are signed out, you are sent to the sign-in page with the link in the page address — see section 8), and you see the project only if the organisation has given your account access.

Feasibility share viewers. Anyone with the link can view one scenario’s figures without signing in. Purchaser names and contact details are removed before display. We count views and note the time of the last view; we do not record your identity. As described in section 3.6, we do keep a per-address request counter that contains your IP address, and if you exceed the limit that counter is written to our logs and error monitor.

Suppliers who email invoices. See section 3.5.

People named in project records. Organisations record property purchasers (name, email, phone, solicitor, prices and deposits), client contacts, sales agents, companies and sole traders (ABN, address, email, phone), site visitors (name, company, purpose, time on site), labour counts by company and trade (no individual workers are named), meeting attendees, contractor and principal contacts on payment certificates and bank-guarantee receipts (including the address a receipt was emailed to), and applicants named in approval documents. We hold this for the organisation. Some of it may be sent to our AI provider when an organisation uses an AI feature on that record (section 7) and appears in emails the organisation sends through the service (section 10).

Your responsibilities. If you record another person’s information in the service, you must have the right to do so. Our AI provider’s terms also require us, and therefore you, to have the rights needed to submit the content you send to an AI feature.

Your rights if you are one of these people. You can ask the organisation that recorded your information, or us at hello@upscale.build, to access, correct or delete it (section 14). Where the information belongs to an organisation’s records we will work with that organisation to respond.

5. How we use information

We use personal information to:

• provide the service — accounts, projects, files, portals, emails and notifications;
• keep the service secure — sign-in, bot protection, rate limiting, error monitoring;
• bill organisations that subscribe;
• send the emails and notifications described in section 10;
• keep a record in our CRM of who has signed up so we can follow up about the service;
• understand how the website and product are used and measure our advertising;
• run the AI features (section 7);
• respond to support and privacy requests; and
• meet our legal obligations.

We do not sell your personal information to third parties. We do disclose it to the service providers below so the service can work, which is different from selling it.

We do not currently send marketing email from the platform. Any marketing email we send will carry an unsubscribe link.

6. Service providers we share information with

These are the third parties that process personal information for us, what each receives, why, and where it is. Each provider’s own terms govern what it does with the information it receives; for Anthropic those are its commercial terms and data processing addendum, not its consumer privacy policy (section 7).

Two more things involve third parties in a limited way. Three feasibility research features — comparable sales, off-the-plan sales and suggested cost rates — enable Anthropic’s built-in web search (section 7). Anthropic’s own sub-processors are listed in its Trust Center. We do not send the search any personal information or your location, and no other feature uses web search. And the integrations you choose to connect — Dropbox, Google Drive, Microsoft OneDrive and Xero — receive information only when a Super Admin connects them (section 11).

7. AI features and Anthropic

Some features send information to Anthropic (the maker of the Claude AI models) to read a document or draft text for you. This section says exactly what is sent, when, and what happens to it.

What is sent

Nothing is sent to Anthropic until a signed-in user starts an AI feature, with one exception: when you add a document to the Documents module (website or app), its file name — and nothing else — is sent automatically so the document can be classified. You cannot switch this off. Each feature sends only what that feature needs:

• Whole documents you upload for extraction: progress claims, variations, extensions of time, tender submissions, consultant proposals, authority approvals, meeting minutes, programmes, and supplier tax invoices (as PDF or image). Council development control plans are sent as the PDF or its text, together with the site address, council, planning instrument name, zoning, floor-space ratio, height, minimum lot size, site area and heritage status, the file’s name, any follow-up question you type, and — for a follow-up — the previous summary, which is re-read from your cloud storage.
• Records from your project when you ask for an analysis or draft: defect lists (number, name, location, trade, priority, status and the company assigned); an RFI’s subject, question and discussion, together with the project name and the names of the person who raised the RFI, its assignee and the people who wrote each message; site diary entries (date, weather, work done, delays, labour and equipment counts, safety-incident counts, safety notes and free notes), and for the diary drafting feature the previous day’s entry and delay reason; programme tasks; and, for a project report, your organisation’s name, the project’s name, code, address, status, stage and dates, budget, contract, claim, variation, sale and tender totals, retention held, extension-of-time days, RFI and defect counts, milestone names and dates, RFI subjects, risk titles and recent meeting titles, dates and summaries.
• Supplier names and an invoice’s amount, date and number, when the service cannot tell on its own whether a supplier in your register is the same business as one in your accounting ledger.
• Text you type into an AI feature: the context for a draft email (with the recipient’s name and your organisation’s name), feasibility review questions and up to twelve earlier turns of that conversation, questions about a development control plan, and Ask UpScale questions together with the project facts the service is allowed to show you.
• Feasibility scenario figures (revenue, costs, funding, margins and your notes) when you ask for an AI analysis or review.
• For the three feasibility research features, the suburb, state and property or development type (and, for suggested rates, floor area and unit count), plus any Domain.com.au suburb statistics we have already retrieved. Those three features also let Anthropic run web searches based on those details (section 6). Your site’s postcode is used to look up Domain.com.au statistics but is not sent to Anthropic.
• A file name only, for document classification (above).

No account identifier or organisation identifier is attached to a request as metadata; Anthropic sees our API key and the content itself. Personal information — and your organisation’s name — reach Anthropic only where they are inside that content: for example your organisation’s name in a draft email or project report, the names of the people who raised, were assigned or replied to an RFI, or a contractor’s name on a claim. The mobile app never contacts Anthropic directly; it uses the same server features as the website.

How it is sent

Each request is a single, live call made when you press the button (or, for classification, when you add the file), and the answer comes straight back to you. We do not send your data to Anthropic in bulk, in the background, or for any purpose other than answering that request.

Training

Anthropic’s Commercial Terms of Service state: "Anthropic may not train models on Customer Content from Services." Anthropic’s privacy documentation says that, by default, it does not use inputs or outputs from its commercial products, including its API, to train its models, and that the exception is content a customer explicitly reports as feedback. The service has no feedback path to Anthropic, so nothing you send is reported to Anthropic as feedback.

Retention and location

Anthropic’s published position for API customers is that it automatically deletes inputs and outputs from its systems within 30 days of receipt or generation, except where content is flagged by its trust and safety systems (retained up to two years, with classification scores up to seven years) or where the law requires retention. Anthropic does not offer deletion on request for individual API requests. Anthropic stores data at rest in the United States, and AI processing may run in any of Anthropic’s available locations. Content we send to Anthropic is handled under Anthropic’s Commercial Terms of Service and Data Processing Addendum, under which Anthropic acts as our processor; Anthropic’s consumer privacy policy does not apply to it.

What we keep

For every AI feature except Ask UpScale we record which feature was used, when, by which account and organisation, and the model — not token counts, and never the content sent or the answer. For Ask UpScale we keep a record of each run together with your question and the answer, and no model or token record. Answers are returned to you and are not stored by us unless you choose to keep them — for example when you accept an extracted claim, variation, invoice, meeting or approval into your project, or when a development control plan summary is written back into your organisation’s cloud storage (section 3.4). Ask UpScale questions and answers are kept with the project until you delete the thread or your account (section 12). If an answer cannot be read, or contains figures outside a plausible range, its raw text may be written to our short-lived server logs, and the suggested-rates feature shows you the raw text in its error message.

8. Cookies, tracking and browser storage

The website sets the cookies and browser storage below. Google Analytics, the Meta Pixel and PostHog run on ordinary public and signed-in pages, including the tender portal. They are not started — or, after an in-site navigation, are paused — while the current address carries a credential. This covers the client portal, meeting-minutes and feasibility share links themselves; a sign-in address whose next value contains one of those links; and one-time authentication codes or tokens in an invitation, email sign-in or password-recovery address, including tokens after the #. Those credentials remain in the browser address until the authentication screen has consumed them, but analytics events are refused during that time. On an ordinary page, Google Analytics waits until you scroll, tap, click or press a key, or about seven seconds pass, and the Meta Pixel waits for the first of those same actions, or four seconds. PostHog sends only the named events in our tracking plan — never clicks, keystrokes, page titles or screen recordings. Sentry still reports errors on credential-bearing pages, but the credential is removed from the page address, request details, breadcrumbs and performance spans before the report is sent. Its sampled replay is not started on such a page; if a browser already recording an ordinary page navigates to one, recording stops without sending the pending segment. Vercel’s one-hour request log still records the requested address because the request reaches our hosting service before browser code runs.

The mobile app itself sets no cookies. Four screens in the app open a browser: the sign-in bot check (Cloudflare Turnstile row below), Google sign-in (Apple’s system sign-in sheet, which shares Safari’s cookies, so Google’s own sign-in cookies persist there), the "share feedback" link, which opens our public feedback board at feedback.upscale.build inside an in-app Safari view (the board is hosted by Featurebase, which sets its own cookies there and asks you to sign in the first time on each device; we send it nothing about you), and the "open on the web" hand-off, which opens our website signed in inside an in-app Safari view — the website cookies in this section, including a signed-in session, are set there and persist in that view, separately from the app’s own sign-in, until you sign out there or remove the app.

8.1 Cookies

8.2 Browser storage (not cookies)

8.3 Other third-party scripts on the website

• Cloudflare Turnstile loads from challenges.cloudflare.com on the sign-in, sign-up, forgot-password and account-security screens (section 3.6).
• Stripe.js loads on the billing page and sets the Stripe cookies and storage listed above (section 6, Stripe row).
• Google Picker loads from apis.google.com only when a Super Admin chooses to pick a file from Google Drive; it receives the organisation’s Drive access token so the picked file can be copied.
• Sentry loads on every page of the website (section 3.6). On a page whose address carries a share or authentication credential, Sentry removes that credential from error and performance diagnostics, and its sampled session replay is not started or is stopped without sending the pending segment.
• PostHog loads from us-assets.i.posthog.com on ordinary pages and sends events to us.i.posthog.com (section 6, PostHog row). It does not load on a credential-bearing address, and an already loaded instance is switched off while the browser is on one, including when a share-link or authentication credential is nested in a redirect parameter or placed after the #. It records no clicks, keystrokes, page titles or screen recordings — only the named events in our tracking plan.

8.4 How to opt out of measurement altogether

The Google Analytics opt-out add-on stops Google Analytics collecting from your browser. Meta offers no equivalent: its "Activity from other businesses" control stops Meta using what our pixel sends to personalise ads and content, but the pixel still sends it. To stop the pixel itself, use a content blocker. A content blocker that blocks googletagmanager.com (which stops Google Analytics loading at all), analytics.google.com, google-analytics.com, stats.g.doubleclick.net, connect.facebook.net and facebook.com/tr, us.i.posthog.com and us-assets.i.posthog.com stops all three tools; the website works normally without them. You can also clear or block this site’s cookies and storage in your browser, but the Supabase cookies, and whatever the Cloudflare frame stores, are needed to sign in.

9. Overseas disclosure

Personal information is processed outside Australia. This is the list of where it goes.

We cannot provide the service without these providers — in particular, every record in the service is stored with Supabase in India. By creating an account, inviting someone, or recording another person’s details, you acknowledge that the information will be handled by these providers in these countries under their own privacy terms, summarised in section 6. If you do not want your information sent overseas, you should not use the service, and you can ask us to delete what we hold (section 14).

10. Emails, notifications and how we contact you

Emails from the service. Sent through Postmark, the service emails: team and project invitations; tender invitations, notices, results and cancellations; meeting-minutes share links; payment certificates and bank-guarantee receipts; and a daily or weekly digest of overdue items, claims and variations for internal staff. When a staff member sends a certificate, receipt, invitation or share from the service, their name and organisation appear as the sender and their own email address is the reply-to address, so the recipient can reply to them.

Digest emails go to internal staff only. You can turn them off or change their frequency in your notification preferences, and each one carries an unsubscribe link.

Account emails (sign-up confirmation, password reset and email-change confirmation) are generated by Supabase’s authentication service and delivered either by Supabase’s own mailer or through Postmark (section 6), depending on our mail configuration.

Push notifications (mobile app), when push delivery is enabled on our side, are sent through Apple’s notification service to internal members of a project when a claim is certified or paid, a variation is approved or rejected, or an extension of time is submitted, approved or rejected. They contain the item’s number and status, the project’s name and code, and the internal identifiers of the project and record so a tap can open the right screen — no amounts, names or other content. You can switch these off per event type in the app under Settings → Notifications, or turn off notifications for the app in your device settings. If Apple reports that a device token is no longer valid, we delete it. Signing out stops notifications on that device and removes your device token from our records; if the device is offline at the time, the token is removed when the device next registers, when Apple next rejects it, or when your account is deleted.

11. Integrations you choose to connect

Nothing in this section happens until a Super Admin of your organisation connects the integration, and each can be disconnected by a Super Admin in Settings.

Dropbox, Google Drive or Microsoft OneDrive. We ask for the narrowest access each provider offers for our purpose: Dropbox account info, file metadata, file content read and write; Google Drive access limited to files the app creates or you pick ("drive.file"); Microsoft read and write of the signed-in user’s files. We create a visible "UpScale Projects" folder tree and write your files there, read listings and file contents back from that tree, and copy files a Super Admin picks from elsewhere in the drive. Access tokens are encrypted with AES-256-GCM before they are stored, and the encrypted values cannot be read by the website or app. Disconnecting deletes our copy of the tokens and does not delete your files. It does not cancel the permission at the provider — to fully revoke it, remove UpScale from your Dropbox, Google or Microsoft account’s connected-apps settings. Where your files then live depends on your own provider account: Dropbox stores in the United States by default (other regions apply only to eligible team plans); Google stores on servers around the world; Microsoft stores in your region, the United States and other jurisdictions where it operates.

Xero. Read-only access to invoices, contacts and organisation settings. The service reads your supplier bills (invoice number, dates, status, amounts, and the supplier contact’s name and tax number) to reconcile them against a project’s invoice register, and can add one bill at a time to the register as a proposal for you to confirm. Nothing is ever written to Xero. Disconnecting asks Xero to revoke the permission and deletes our copy of the tokens. If Xero does not confirm the revocation you are not told, so to be certain also remove UpScale under Xero’s Connected apps. Xero states that personal data may be processed in Australia, New Zealand and the United States.

12. How long we keep information, and deletion

We retain your data for as long as your account is active. There is no automatic purge; information stays until you or your organisation delete it, or until an account is deleted. Email addresses given to our earlier waitlist form are kept until you ask us to delete them (section 14); the form is no longer in use.

Deleting your account

You can delete your account yourself, in Settings on the website or in the app. The service first shows you what will happen, and the deletion is immediate — there is no grace period and no undo. It works like this:

• Your account and everything only about you — profile, sign-in identities, device tokens, notification preferences, your organisation and project memberships, AI usage records, access grants issued to you, meeting-minutes shares addressed to you, the record of tender documents you downloaded (so an organisation relying on download receipts should export them before a tenderer leaves), and our own internal record of the sign-up we passed to our CRM — are deleted with the account. The contact record HubSpot itself holds is not removed automatically (see below).
• Records you authored (RFIs, defects, decisions, uploads, risks and so on) stay with your organisation, with your name removed, where another member needs them. Ask UpScale conversations you started are the exception: they are deleted with your account, including for other members of your organisation.
• An organisation in which nobody else remains is deleted with your account, along with all of its projects and records.
• Deletion is refused in one case only: if you are the last Super Admin of an organisation that still has other members (make someone else a Super Admin, or remove everyone else from the organisation, first). A paid subscription does not stop you deleting your account. If an organisation only you occupy is billed through our website, we cancel that subscription with Stripe before the organisation is deleted; if the cancellation cannot be confirmed, your account is not deleted and the app asks you to try again. An App Store subscription is not cancelled for you (see below). Deletion also cannot complete while an organisation that other members keep still holds financial period snapshots, cash-flow waterfalls or a Xero connection you created; the app will tell you it failed, and any organisation only you occupied will already have been deleted. Email us and we will finish the deletion by hand. If a deletion cannot complete for any other technical reason, the app tells you and we will finish it manually on request.

What deletion does not remove

• Files in your own cloud storage (Dropbox, Google Drive, OneDrive) — they are yours and stay where they are.
• Files in our own storage — organisation logos and files uploaded before we moved to customer-connected storage are not removed automatically when an account or organisation is deleted. Email us and we will delete them.
• Your organisation’s Stripe customer record — we do not delete it; Stripe keeps it under its own retention (five or more years).
• An App Store subscription — we cannot cancel it for you, and Apple keeps the purchase record under its own terms. Cancel it in Settings → your name → Subscriptions on your device before you delete your account, or it keeps renewing with Apple.
• Your HubSpot contact record — it is not removed automatically. Tell us when you delete your account and we will remove it.
• Copies held by providers for their retention windows — see the table below.
• Some technical records — sign-in hand-off records and rate-limit counters (which include IP addresses on public pages) are not currently purged. Some append-only records — project activity histories, notification delivery records, project drafts, Ask UpScale audit events and action proposals, and sign-in hand-off records — keep an internal identifier that no longer links to anyone once the account is deleted. Invoice-email manifests (section 3.5) stay with the project.
• Email addresses recorded as evidence of a communication stay with the record they belong to even after the person’s account is deleted or they leave an organisation: a tenderer’s contact email and the tender emails sent to it, the address meeting minutes were shared with, the address a bank-guarantee receipt was sent to, and client-contact and sole-trader company records. Ask us or the organisation to remove them (section 14).

Provider retention after deletion

Archived projects

An organisation can archive a project. Archived projects are read-only for everyone until reactivated; share links for them can still be revoked.

13. Security

The measures below are what is in place. No system is completely secure, and we cannot guarantee against every risk.

• Encryption in transit and at rest. The website and API are only served over HTTPS (with HSTS). Supabase states that all customer data is encrypted at rest with AES-256 and in transit with TLS, and that it is SOC 2 Type 2 and ISO 27001 certified.
• Tenant isolation. Every table in our database has row-level security enabled. Policies limit each query to the caller’s organisation, then to the projects they are a member of, then to what their role and permissions allow. These policies bind every query made by the website and app on your behalf. Our own server code that must act across organisations (invitations, billing, account deletion, inbound email) uses a privileged connection that bypasses them after making its own checks. Automated cross-tenant tests are run in our test pipeline against every change to the database schema.
• Roles and permissions. Super Admins control organisation membership and integrations; project roles and per-module permissions control what internal members, clients, consultants and contractors can see and do. Only internal users can delete records. Archived projects are read-only.
• Files. Files in your cloud storage are served only through links that check your access to that project and module. Our own storage is private except organisation logos.
• Credentials. Passwords are hashed by our authentication provider. Integration tokens are encrypted before storage and the encrypted values are unreadable by the website and app. Changing your email or password requires your current password, and you can sign out every other session from Settings. If you sign in with Google or Apple and have not set a password, your email address is managed by that provider and cannot be changed in Settings; email us if you need the address on your account changed. We do not currently offer two-factor authentication.
• Payments. Card details never touch our servers.
• Abuse protection. Bot checks on sign-in and sign-up; rate limits on public share pages and costly features; webhook messages from Stripe, Postmark and Xero are verified before they are processed.
• Mobile app. Your session is held in the device Keychain in a device-bound protection class: any backup copy is encrypted with a key unique to that device, so it cannot be restored onto another device. Signing out clears the app’s cached copies of project data and removes your session from the device. It does not sign you out of the website session opened by an "open on the web" hand-off inside the app’s browser view — sign out there as well — and offline drafts stay on the device. Offline drafts, including ones already sent, which are kept as receipts, are encrypted on the device with a key held in the Keychain; they are not cleared at sign-out and stay until you discard them or remove the app.
• Emailed invoices. Attachments are not virus-scanned by us; treat them as you would any email attachment.

If a data breach is likely to result in serious harm, we will notify affected people and the Office of the Australian Information Commissioner as the Privacy Act requires.

14. Access, correction, deletion and complaints

Do it yourself. In Settings you can change your name, time zone and notification preferences, change your email address and password (if you sign in with one), sign out other sessions and delete your account. If you sign in with Google or Apple and have not set a password, your email address is managed by that provider and cannot be changed in Settings — email us if you need the address on your account changed. Super Admins can change the organisation’s name, colour and logo and disconnect integrations in Settings. Share links are revoked from the project they belong to.

Ask us. There is no self-service export yet. Email hello@upscale.build to ask for a copy of the personal information we hold about you, to correct something you cannot change yourself, or to delete information. If you are not an account holder but your information is in an organisation’s records (section 4), we will work with that organisation to respond. We aim to respond within 30 days.

Complaints. If you think we have mishandled your personal information, email hello@upscale.build with "Privacy complaint" in the subject. We will acknowledge it, investigate, and tell you the outcome. If you are not satisfied, you can complain to the Office of the Australian Information Commissioner (OAIC), www.oaic.gov.au.

15. Children

UpScale.build is a business tool for property developers and builders. It is not directed at children and we do not knowingly collect personal information from anyone under 18. If you believe a child has created an account, email hello@upscale.build and we will delete it.

16. Changes to this policy

We may update this policy from time to time. The date at the top shows when it last changed. Where a change materially affects how we handle your information we will tell account holders by email.

17. Contact

For privacy enquiries, requests or complaints, contact us at hello@upscale.build.