What we hold, how long we keep it, and what happens when you ask us to delete it.
Where a minor’s privacy and somebody’s convenience are in conflict, we choose privacy and tell you we have done so.
A provider’s home address, school, exact age and date of birth are never shown publicly and are never sent to analytics.
For everybody: an email address, and a password held by our hosting provider in a form we cannot read.
For providers: a first name shown publicly, a date of birth that is never shown to anyone, and for a provider under 18, a guardian’s contact details and their signed consent.
For customers: the service address, any access notes such as a gate code, and a record of what was charged.
Card numbers are never held by us. They go directly to Stripe.
Because registration asks for date of birth, review the under-13 rejection flow for COPPA. Engineering traced this on 2026-09-01 and the answer is partly, which counsel should have before advising. What is already true: an under-13 date of birth is refused by startProviderOnboarding before any provider profile row is written, so the birth date itself is never stored, and the audit row recording the refusal redacts it. Nothing is sent to analytics, because no analytics vendor exists. What is not true: the date of birth is asked for after the person has already signed up, so at the moment we learn they are under 13 an authenticated account already exists holding their email address, and nothing deletes it. An audit row keyed to that account also remains. So the product has actual knowledge of an under-13 user and retains an email address and an audit record for them, with no parental consent. Counsel should say what is required: delete the account outright, retain a minimal blocked-signup marker to stop immediate re-registration with a corrected date, or something else. This is a required code change, not wording.
A customer’s service address is shown only to that customer, the provider doing the work, that provider’s connected guardian, and staff handling a specific report. Every time a member of staff views an address, that is recorded with their name and their reason.
Gate and access codes are treated as more sensitive than the address. They appear on the provider’s route screen and nowhere else — never in an email, a notification preview, a log, or an analytics record.
A provider may add one photo when they finish a visit. It is optional; nothing is blocked if they do not.
Location data and other metadata are removed from the photo before it is stored, not before it is shown. The original is never kept.
Photos are private. They can be seen by the provider, the customer, that provider’s connected guardian, and staff handling a report — nobody else, and there is no shareable link.
We measure how the product is used. Analytics works from a list of fields that are explicitly permitted, so a new field is excluded until somebody adds it deliberately.
Postal codes sent to analytics are shortened to three digits. Addresses, names, dates of birth and access codes are never sent.
Nothing is kept indefinitely. Every kind of record has a period, and a daily job enforces it.
Messages between neighbours: one year. Messages that have been reported or blocked: three years, because they are evidence about somebody’s safety.
Completion photos and service addresses: six months after they are no longer needed — long enough to still evidence a visit if a card payment is disputed months later.
Records of notifications we sent: ninety days.
Financial records, the audit log, safety reports and account decisions: seven years.
Guardian consent: seven years, counted from when the guardian relationship ends rather than from the day it was signed.
Contact details on an account: while the account is in use, and for seven years after it closes or falls completely silent.
Approve or change these periods. Product’s position is that it prefers defensible retention over aggressive deletion. Review state privacy-law requirements, litigation/safety holds, payment-record requirements, and records involving minors. If any record may legally or operationally be retained without a fixed end date, change the opening sentence so the public notice does not promise the opposite.
You can close your account from your account page. Before you confirm, we show you exactly what will be removed and exactly what will be kept, and why.
We do not claim to erase everything, because we cannot and should not. What goes immediately: your contact details, your display name, your addresses including the map coordinates, records of notifications we sent you, your completion photos, and messages you sent.
What stays: financial records, the audit log, safety reports, account decisions, and guardian consent — each for its retention period. Direct account identifiers are removed where possible, while retained records remain associated with an internal account reference.
Two things we will not do: erase a message that has been reported about your conduct, and complete account closure while money is still owed to you or a subscription is still running. The second protects you — it is your money, and for a provider aged 13 to 17 it is paid through the connected guardian’s Stripe/payment account.
Whether any applicable deletion right overrides refusing closure while earnings are unpaid or a subscription is live; whether retained records remain personal information under applicable law even after direct identifiers are removed; and whether records created while a provider was a minor need different treatment once that provider turns 18.
Stripe, to take payments and to pay providers. Our email provider, to send you messages. Our hosting provider, which also runs our database and holds the passwords used to sign in.
We do not sell your information. We do not currently send your information to an analytics provider.
The full subprocessor list with each one named, international transfer position, state-specific privacy rights and how they are exercised, cookie/tracking disclosure, sale/share/targeted-advertising definitions if applicable, and the retention wording that pairs with the periods above. Two changes from the 2026-09-01 review were not adopted, because both named a recipient that does not exist. There is no analytics provider: the analytics boundary in src/server/analytics.ts runs NullSink, which drops every event, and no vendor has been chosen. Authentication is not a separate company — it is Supabase, the same vendor as hosting and the database — so listing it separately implied a fourth party. If an analytics vendor is added before launch, this section and the sentence denying one must change in the same commit.
The EDW Ventures LLC contact route for privacy requests, who is responsible, required identity-verification process, and the response timing required or promised.