Data Protection and Disaster Recovery

This page describes Bildr's current application-level controls, infrastructure providers, and recovery dependencies. It supplements our Privacy Policy and Terms of Service.

Unless a separate written agreement says otherwise, this page does not create a contractual uptime, backup-retention, recovery-point, recovery-time, or incident-response guarantee. Provider capabilities depend on the active service plan, region, configuration, and provider terms.

Bildr's architecture is distributed across the following service providers:

Provider company location, configured data region, and actual processing location are different concepts. Some providers may process information outside Australia. Each provider publishes its own current security, privacy, regional-processing, and certification documentation. Those controls can vary by product and plan and should not be read as a Bildr guarantee. See our Privacy Policy for disclosure details.

Database recovery: Bildr relies on the backup and recovery features enabled for the active Supabase plan and project configuration. We do not publish a fixed snapshot frequency or retention period until those settings and a restore test have been verified.

File storage: Uploaded documents are stored in Supabase Storage. Provider durability or redundancy is not the same as an independent customer-file backup. Keep original copies of plans, reports, quotes, and photos outside Bildr.

Application code: Source code is version-controlled and Vercel supports deployment rollback. Recovery time depends on the incident, database compatibility, provider availability, and operator access.

Payment data: Stripe maintains its own PCI DSS Level 1 certified infrastructure with independent backup and disaster recovery procedures. Bildr does not store credit card numbers, CVVs, or full payment credentials. Only Stripe customer IDs and subscription status are stored in our database.

Bildr does not currently offer a contractual Recovery Point Objective (RPO) or Recovery Time Objective (RTO). Recovery depends on the failure mode, available provider backups, data integrity, provider status, operator access, and tested runbooks.

Current recovery approach:

• Application defects: Operators can investigate logs and use Vercel deployment rollback where appropriate.
• Database or storage incidents: Recovery options depend on the active Supabase plan, project settings, and provider support. A restore may be incomplete or unavailable.
• Third-party outages: AI, payment, email, monitoring, authentication, storage, or application features may be degraded or unavailable while a dependency is down.
• User responsibility: Export important project records and keep original documents and independent financial records outside Bildr.

Transport and storage controls: Bildr uses HTTPS/TLS connections and provider-managed at-rest protection where supplied by the configured service. Exact implementations are documented by each provider.

Authentication: User authentication is managed by Supabase Auth. Protected application routes require authentication and, where appropriate, project-ownership checks. Some endpoints are intentionally public, including health, lead capture, payment webhooks, and founding-count routes.

Database access: Row-level security supports direct user-scoped database access. Privileged server operations can bypass RLS and therefore use separate application authentication and ownership checks. No single control guarantees prevention of every cross-user access vulnerability.

Rate and cost controls: Selected sensitive and AI endpoints use rate limits, usage caps, or generation locks. This does not mean every endpoint is rate-limited or that denial-of-service risk is eliminated.

Monitoring: Sentry is configured for application error telemetry and a public health endpoint is available at /api/health. A health endpoint alone is not continuous external uptime monitoring, and telemetry can be incomplete.

Change checks: The repository includes automated linting, type checks, tests, and dependency-audit steps. Their execution and enforcement depend on the configured CI and repository settings.

Our data retention policies are detailed in our Privacy Policy. In summary:

• Account data: Project data is retained while the account exists. Cancelling a subscription does not itself trigger an automatic 90-day purge.
• Account deletion: The in-app workflow cancels active billing and attempts to remove application database records, uploaded files, and authentication credentials. External payment, tax, security, provider-log, and backup records may remain where required or until provider retention and rotation complete.
• Data export: Users may download a free raw JSON export of their account and project records immediately from Account settings. For email delivery, the five-NSW-business-day manual period starts after support@bildr.au receives a complete request and verifies the account holder's identity. Uploaded binary files are handled separately through support.

In the event of a data breach or security incident, Bildr Labs will:

• Investigate, contain, and remediate the incident as circumstances permit
• Assess whether the incident is an eligible data breach under applicable Australian law
• Notify affected individuals and the Office of the Australian Information Commissioner (OAIC) as soon as practicable where required by the Notifiable Data Breaches scheme
• Provide affected users with a clear description of the breach, the data involved, and recommended actions
• Implement corrective measures to prevent recurrence

Security concerns can be reported to support@bildr.au.

Depending on the circumstances and legal thresholds that apply, Bildr's handling of information may be subject to requirements including:

• Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs)
• Notifiable Data Breaches (NDB) scheme: assessment and notification obligations where an eligible data breach occurs
• Spam Act 2003 (Cth): consent, sender-identification, and unsubscribe requirements for commercial electronic messages
• APP 8 (Cross-border disclosure): steps relating to overseas disclosures where the APPs apply

This page describes operational measures and is not a blanket representation that every statute or APP applies to Bildr in every circumstance, or that the controls eliminate all legal or security risk. Provider certifications, contractual protections, processing locations, and available controls vary by service and plan and require ongoing review.

Bildr depends on multiple third-party services. This reduces some infrastructure-management burden but introduces provider and integration failure modes:

• Application: Vercel hosts the web application and functions; a Vercel, DNS, deployment, or regional issue may affect access.
• Core data: Supabase provides authentication, database, and storage; an outage may affect login and access to project records.
• AI: Anthropic and OpenAI outages can prevent chat, generation, quote review, or document extraction.
• Payments and email: Stripe and Resend availability affects billing and message delivery. Their independent continuity controls are governed by their own terms.