Legal

Privacy Policy

What we collect, why we collect it, who else touches it, and how long we keep it.

Last updated 18 August 2026

Unreviewed draft. This document was written to describe how Buildchute actually works, not by a lawyer. It has not been checked against GDPR, CCPA, or Nigerian data-protection law, and every [BRACKETED] value still needs filling in. Get it reviewed before taking payment.

1.Who we are

Buildchute is operated by [LEGAL ENTITY NAME], registered at [REGISTERED ADDRESS]. For anything in this policy, reach us at [privacy@buildchute.com].

We are the data controller for account and usage data. Where you upload builds, you are the controller of what's inside them and we act as your processor.

2.What we collect

Account data. When you sign in with GitHub or Google we receive your name, email address, and avatar URL from that provider. We never receive or store your password, and we don't request repository access.

Build data. The binary you upload, plus what we read out of it: app name, bundle identifier, version, build number, file size, icon, signing certificate expiry, and — for iOS — the device identifiers listed in the provisioning profile.

Install data. When someone opens an install link we record the time, the build, the IP address, and the browser and operating system reported by the request. This is what produces the install audit trail.

Payment data. Handled entirely by our payment provider. We receive the plan, status, and last four digits of the card. We never see full card numbers.

3.Device identifiers

This deserves its own clause. iOS provisioning profiles contain device UDIDs, and a UDID identifies a specific physical device — which makes it personal data under GDPR even though it looks like a machine string.

We extract UDIDs so we can tell a tester their device isn't registered before they attempt an install. We show a UDID only to that device's own visitor and to members of the workspace that owns the build. We do not use device identifiers for advertising, tracking across sites, or profiling, and we do not sell them.

4.Why we process it

  • To perform the contract — storing builds, minting install links, enforcing access rules and plan limits.
  • Legitimate interests — preventing abuse, debugging failures, and keeping an install audit trail that workspace owners rely on.
  • Legal obligation — tax and accounting records for payments.

5.Who else touches your data

We use a small number of sub-processors. Each gets only what it needs:

  • Byteship — object storage and CDN delivery for build binaries and icons.
  • Bachs — payments, subscriptions and invoices.
  • Resend — transactional email such as tester invites and expiry warnings.
  • Sentry — error reports, which may incidentally include a URL or account identifier.
  • PostHog — product analytics on the dashboard. Install pages are excluded, so testers aren't analytics-tracked.

We host on infrastructure we control at [HOSTING REGION]. We don't sell personal data, and we don't share it with advertisers.

6.How long we keep it

Build binaries are deleted automatically when their retention window ends — between 7 days and one year depending on plan. That deletion is real, not a flag.

Build metadata and install records are kept for the life of the workspace so the audit trail stays intact, then deleted within [30] days of workspace deletion. Payment and tax records are kept for [7] years as required by law.

7.Your rights

Depending on where you live you can request access to your data, correction, deletion, a portable copy, or object to processing based on legitimate interests. Email [privacy@buildchute.com] and we'll respond within 30 days.

You can delete your workspace yourself at any time, which removes the builds with it. If you're in the EU or UK you may also complain to your local data-protection authority.

8.Security

Builds are stored privately and never given a public URL. Every download goes through a short-lived signed link, so a leaked link stops working on its own. Access to production data is limited to people who need it, and credentials are scoped so a leaked CI token can upload to one app and nothing else.

No system is perfectly secure. If we discover a breach affecting your data we'll notify you and, where required, the relevant authority within 72 hours.

9.Changes to this policy

If we change how we use your data in a way that materially affects you, we'll email workspace owners before it takes effect. Smaller edits get a new date at the top.