Your idea is product data—not ad inventory.

Information we handle

• Account data: name, email, password hash, session records, plan state, and workspace membership.
• Product data: the briefs, project models, screens, entities, roles, workflows, assets, and runtime records you choose to create.
• Operational data: build status, audit activity, storage metadata, subscription records, and service errors needed to run and secure the platform.
• Product-map preview: the server processes your answers to return the preview but does not store those answers unless you explicitly save the map.
• Saved product-map claim: choosing to save creates a private seven-day draft linked to an opaque browser cookie. The raw brief and context are removed from that claim record after the map becomes a project artifact.

Conversion measurement without reading the idea

The acquisition funnel records allowlisted events such as landing view, map submitted, signup completed, and project created. These events use a pseudonymous browser identifier and coarse properties such as template type. They do not contain the brief, email, name, raw IP address, user agent, or full referrer.

Why we use the information

We use it to authenticate BuildMakr staff/workspace members, create and operate workspaces, generate the requested project, enforce plan limits, process uploads, diagnose failures, prevent abuse, and understand whether the BuildMakr signup journey works. Mobile build data is sent externally only when the deployment operator has activated a provider and a user submits a job.

Cookies and retention

• Session and OAuth cookies support secure sign-in.
• The product-map claim cookie is HttpOnly, SameSite=Lax, and expires after seven days.
• Expired, non-materialized product-map drafts are removed during routine cleanup.
• You can discard a saved, non-materialized map from the product-map interface before that deadline.
• Pseudonymous funnel events are retained for up to 90 days.
• Account and project data remains until deleted under the operator's retention process or as required for legal and security obligations.

Infrastructure and service providers

The deployment uses or may use Postgres, Redis, S3-compatible object storage, Stripe, Google OAuth, and a configured transactional-email provider. Expo Application Services receives build data only if the deployment operator completes provider activation and a job is accepted. A provider should receive only the data needed for the service you activate. Credentials and production providers must be configured by the deployment operator.

Your choices

You can preview without saving, discard a saved draft in the product-map interface, skip the pre-signup map, or create an account directly. You may request access, correction, export, or deletion from the organization operating this deployment. Before commercial launch, that operator should publish a dedicated privacy contact and any jurisdiction-specific disclosures that apply.