What Makerstead collects, how it is used, and how to reach us about it.

This policy explains, in plain language, how Makerstead (“we,” “us,” or “our”) handles personal data collected through the makerstead.app website, the maker bench, the public care pages, and every form, contact channel, QR-handoff, and subscription surface that sits behind them. It applies to every maker who signs up, every owner who scans or visits, and every visitor who lands on the public site. If something here is unclear, reach us through the link above — we would rather answer than have you guess.

The data we hold depends on which audience you are part of. The lists below are exhaustive within each group.

From makers who sign up

• Account— the Better-Auth-managed User, Account, and Session rows for the maker: account email, hashed password, and the session metadata that holds your sign-in state.
• Business — one Maker row per sign-up, with the chosen MakerCategory (the 16 trade ids), the profile JSON, and the status / approval timestamps.
• Record — each Productrow a maker publishes: slug, photo, summary, care text, spec grid. When ownership changes hands, the new owner’s contact and display name are stamped onto currentOwnerContactId and currentOwnerName, plus a currentOwnerEditToken that lets the new owner correct those fields without creating an account.
• Document — the ServiceEntry rows a maker logs against a record: date, kind (repair, refinish, restoration, other, note), notes, optional photo, and optional cost. The publicNote field is the customer-facing variant that we render on the public care page.
• Billing records: the Stripe-managed subscription state and the history surfaced through the in-app Billing page. Card details never touch Makerstead servers — Stripe holds them on its hosted checkout.
• Support history: messages you have exchanged with us about your account.

From owners, customers, and visitors

• Customer-submitted photo— when an owner scans a record’s QR and writes in, we store the CareRequest row with name, email, optional phone, topic, the message, and the photoUrls list they uploaded through the /care/[id]/… page.
• Contact-form submissions saved as ContactMessage rows (name, email, message, timestamp), stored by the contact-form module on our behalf.
• Pilot-interest submissions: name, email, the closest category you selected, and any free-text note you wrote.
• Referral-capture submissions: optional name, optional email, optional owner email, the product slug, and the referral token that scoped the link.
• Usage metadata— visitor behaviour on the public site: a single first-party beacon rendered by src/components/polsia-analytics.tsx (gated on POLSIA_ANALYTICS_SLUG and POLSIA_API_BASE_URL); the Meta Pixel on the marketing site, gated by the advertising_opt_in localStorage entry with a 365-day lifetime; and the form-submission rows written by contact, pilot-interest, and referral-capture.

If you run a maker business — staff roles

If you run a maker business, your owner can invite other people to your bench with one of four roles: owner, office, technician, or readonly. Each invitation stores the invitee’s email, the role assigned, the invitation’s token, and the lastSentEmailId of the invite. Active members are tracked on Membership; their access is scoped per business. An ActivityEvent log records who did what at which role over time, and removing a member keeps historical entries attributed by a cached email so the audit trail stays intact.

When a record changes hands — ownership transfer

When a buyer (or the maker on their behalf) asks to hand a record to a new owner — by visiting the record’s public care page, scanning its QR, or following an accept-transfer link — an OwnershipTransfer row is stored with both email addresses, the current state (pending, awaits_approval, accepted, revoked, reversed), and any reverseOfTransferIdlinkage. Makers can require two-party approval or auto-approve; on accept, the record’s currentOwnerContactId and currentOwnerName are stamped onto the Product, and a currentOwnerEditToken lets the new owner correct their name and email without creating an account.

If a business has more than one branch

A maker business can run more than one physical branch. Each branch is a Location row with its own name, address, hours (Json), isPrimary flag, and isArchived soft-delete flag. The branch a piece, service entry, or care request belongs to is recorded via locationId. Closing a branch archives it instead of deleting it, so historical rows keep their attribution.

• Service delivery — running the bench and serving the care pages.
• Billing — issuing invoices, charging subscriptions, and showing you your payment history in the Billing page.
• Anti-fraud and security — protecting accounts, detecting abuse, and keeping Makerstead available.
• Support — answering your questions and routing them to the right desk.
• Legal compliance — keeping the records we need for tax, audit, and regulatory purposes.
• Aggregated product analytics on the public site only — to understand which pages are useful and which need work.

For visitors in the EEA, UK, or any jurisdiction that recognises a lawful-basis test, we rely on the following:

• Contract— to deliver the bench, publish your care pages, and run billing for an active subscription.
• Legitimate interest— to secure the platform, prevent fraud, and understand aggregated use of the public site.
• Consent— for the Meta pixel on the public marketing site, gated by the consent banner and stored in the advertising_opt_in localStorage entry (365-day lifetime).

Makerstead is the controller for the data it holds on its own behalf: maker account records (the Better-Auth User / Account / Session rows), Makerstead billing and subscription state, staff roles and invitations on a Maker bench, and aggregated visitor analytics on the public site (the first-party polsia_vid beacon and the consent-banner-gated Meta Pixel with id 1936147470383121). When you sign a Makerstead customer agreement you are contracting with us.

Makerstead is the processor for the end-customer data a maker controls inside their Maker: the pieces they publish (Product and its photos, summaries, and care text), the ServiceEntry rows they log, the OwnershipTransfer and approval history, and the CareRequestrows that end customers send in. For that data the maker is the controller and Makerstead processes it on their documented instructions only — to display the care page, deliver the maker's notifications, and persist the audit trail. A maker can export or delete end-customer data they hold at any time; end customers can make the same request directly to the maker, or to Makerstead as set out in this policy.

Makerstead does not sell or share your personal data for cross-context advertising. We share the minimum data required for each service to do its job. The full vendor list, in plain language:

• Better Auth— authenticates your maker account and holds your 30-day session cookie. Receives: account email, hashed password, and session metadata.
• Stripe— handles checkout, recurring billing, and subscription state. Receives: card details (hosted-only), billing email, and amount. The Stripe SDK never ships in our code — the stripe-billing module talks to Stripe through a server proxy.
• Polsia platform beacon— a single first-party visitor beacon on public routes. Receives: a hashed visitor identifier and the page URL. No IP address, no per-user profile.
• Meta Pixel— a paid-social measurement pixel that only loads on the public marketing site after you opt in through the cookie banner. Receives: page URL and the standard Meta conversion events.
• Email module— transactional mailer (welcome, password reset, subscription alerts). Receives: your account email and the message body for that transaction only. No marketing list is ever built or exported.
• Contact-form module— stores ContactMessage rows. Receives: name, email, message, timestamp.
• PDF module— renders Care Passports and other printable surfaces as PDFs. Receives: only the data you have chosen to publish on that record — no incidental PII.
• Auth proxy— a route handler owned by the platform that fronts third-party auth and payment providers. Receives a signed request and passes the response back.
• Cloudflare R2 (via the Polsia storage proxy, cdn.polsia.com) — object storage for everything the platform uploads: Maker piece photos (Product.photoUrl), Maker-logged service-entry photos (ServiceEntry.photoUrl), the photos an end customer attaches when sending a care request (CareRequest.photoUrls[]), and generated PDFs (Care Passports and /api/pdf/document artifacts). Receive is handled by src/lib/server/r2-upload.ts, which POSTs each upload to https://polsia.com/api/proxy/r2; the bucket itself is hosted on Cloudflare R2 and served back from cdn.polsia.com.
• AI on your data: none— Makerstead does not call any AI service on the data you store, share, or upload. The ai capability module is not installed; there is no openai SDK, polsia.com/api/proxy/openai, /api/agent, or third-party model call anywhere in the source. We do not use your records, service entries, care-request photos, or contact-form messages to train, fine-tune, evaluate, or compute embeddings against any model. If we add an AI feature later, this page will be updated before any AI sub-processor sees your data, and substantive changes will go through the change process below.

We do not duplicate the cookie list here — see the cookies page for the exhaustive list, including vendor names, types, and lifetimes. The short version: one sign-in cookie (essential), one theme preference (browser localStorage), a single first-party visitor beacon on the public site (analytics), and an opt-in Meta pixel (advertising). The opt-in choice persists for 365 days in the advertising_opt_in localStorage entry; you can change it at any time from the small pill in the bottom corner.

We are explicit about what is deleted automatically (a scheduled job in polsia.toml), what is kept for the lifetime of an account, and what is held until you ask us to delete it. Where a claim below says “on request,” a scheduled sweep is planned but does not run today — if you want a row deleted sooner, send a privacy request and we will delete it within thirty days.

• Active maker records:live for the lifetime of an active subscription. You can export everything you stored from the dashboard's Export action at any time during that period. After cancellation, the rows continue to live until you ask for deletion — we do not advertise a fixed post-cancel grace window because no scheduled sweep enforces one today.
• Bench invitations— automatically expired by the expire-invitationsscheduled job after the configured window (the invitation token and the row go away; the invitee's email is dropped with them).
• Pending ownership transfers — automatically expired by the expire-ownership-transfer-approvals scheduled job when the approval window closes without action.
• Session cookies (Better Auth): 30 days, refreshed on each sign-in.
• Meta Pixel data:up to 90 days (Meta’s default). We retain nothing on our side beyond the pixel call itself; data older than 90 days sits in Meta's systems under their retention rules.
• Contact-form submissions (ContactMessage rows): retained until you ask. Planned to be swept at 24 months; today the row is only deleted when you submit a privacy request or the desk decides it has answered the question.
• Support-ticket personal data: retained until you ask. Planned to be swept at 24 months for tax and compliance; today the row is only deleted on a privacy request.
• Aggregated public-site analytics: the first-party polsia_vid beacon holds a hashed visitor identifier in localStoragefor the lifetime of the browser — clear your site data to reset it. The visit counts the desk uses to understand which pages are useful are aggregated and carry no personal identifier, so they are kept indefinitely.

You can ask Makerstead to:

• Access— provide a copy of the personal data we hold for you.
• Correct— fix anything that is wrong or out of date.
• Export— download a full archive of your records and service log from the dashboard Export action at any time during the subscription and through the 90-day post-cancel window.
• Delete— erase the records you stored on Makerstead. Subscription state held by Stripe is governed by Stripe’s own retention rules.
• Portability— receive your data in a structured, commonly used format.

Send any request through Contact & support. We acknowledge within two business days and complete most requests within thirty days.

Makerstead is not directed at children. We do not knowingly collect personal information from anyone under 13 (the COPPA threshold in the United States) or under 16 (the GDPR-K threshold in the EEA). If you believe a child has signed up, send us a note through Contact & support and we will delete the account.

EEA / UK (GDPR)

If you are in the European Economic Area or the United Kingdom, you have the right to access, rectify, erase, restrict, port, and object to the processing of your personal data, and to complain to your supervisory authority. The lawful bases we rely on for each purpose are listed above. International transfers from the EEA to Makerstead’s processors are governed by Standard Contractual Clauses and equivalent safeguards.

California (CCPA / CPRA)

If you are a California resident, you have the right to know what personal information we have collected, to delete it, to correct it, to limit the use of sensitive personal information, and to opt out of any sale or sharing for cross-context behavioural advertising. Makerstead does not sell or share your personal data for cross-context advertising. The Meta pixel only loads on the public site if you opt in through the consent banner, with a 365-day lifetime that you can revoke at any time.

Some of our processors (Stripe, Meta) are based outside your home country. Where data crosses borders, we rely on Standard Contractual Clauses, equivalent adequacy decisions, or the processor’s published data-residency commitments. Our database is hosted in the United States; if a region-specific residency option becomes available we will surface it on this page.

We will update this page whenever the policy changes in a material way and bump the version date below. For material changes — a new processor, a new category of data, a new retention rule, a change to controller/processor roles — active makers are notified at the contact email on file (delivered via the email module, same channel as subscription alerts) and given at least 30 days before the change takes effect to raise questions or export the data they hold. Non-material changes (typo fixes, wording) are applied silently and noted in the version date.

The text that was in force immediately before a substantive change remains available on request via Contact & support— tell us which date you want to see and we will send the archived copy and a summary of what changed.

Send any privacy request — access, correction, export, deletion, portability, a complaint, or a question about this policy — through Contact & support. The form on that page writes into the same inbox the desk answers during business hours. We acknowledge within two business days and complete most requests within thirty days.