LOCAL TEST BUILD · DRAFT

Privacy notice draft

This is not a final live privacy notice or a legal compliance promise. The operator/controller identity, contact and operating policies must be supplied and reviewed before public activation.

Who operates the service?

Operator/controller and privacy contact: to be provided before launch. No fictional contact or response service is offered here.

What is stored?

The release source implements storage of account email, salted password hash, server sessions, company details, tariff versions, publication state and calculations explicitly saved by the business in its own PostgreSQL database. It also defines payment/refund/status records, verified provider event identifiers and encrypted recovery messages. Customer calculations are not saved automatically. Do not enter client names, addresses or contacts in calculator or business-scope fields.

An essential HttpOnly session cookie supports sign-in. Current customer controls may stay in this tab's session storage for one company and published tariff version. Unsaved owner edits remain in page memory and can be lost after deliberate discard or forced closure.

Optional analytics

Optional first-party analytics is off before opt-in and follows the implemented DNT/GPC controls. Allowed events cover visits, signup, activation, a main action, checkout and purchase/refund, with test/provider modes separated. Only vetted campaign codes are accepted; no email, name, IP, user agent, full URL/referrer or arbitrary metadata belongs in event payloads. Visit and internal account identifiers are pseudonymous, not a promise of anonymity. Provider conversions can be observed when a consenting owner returns to verified billing state, so their analytics time can differ from payment time and some conversions can be absent. No external analytics SDK is included.

Recovery and payment providers

Production adapters for Resend recovery email and Dodo hosted checkout are implemented but inactive. Contract tests use mock responses; no provider onboarding, email, authenticated API request or payment has occurred for this release. There is no public reset-token inbox. Do not enter real card details in this test build.

After separately approved activation, Resend would process account recovery emails. Recipient, link and token are encrypted in Tidyquote's database outbox before delivery; operational logs exclude them. The sender domain, processor terms and disabled open/click tracking must be accepted first. Provider acceptance does not prove inbox delivery.

After merchant approval and testing, Dodo would collect checkout contact/card details on its hosted page for software subscriptions, not cleaning-job payments. Tidyquote retains the necessary opaque provider references, amount/currency, status, period and verified-event hash. Actual merchant eligibility and processor terms remain unaccepted; Georgian registration alone does not guarantee approval.

Retention and deletion

The code has 30-day analytics expiry with hourly cleanup; real SQL and maintenance acceptance remain pending. Recovery tokens are single-use and expire within 15 minutes; queued messages use 14 minutes, at most five attempts, five queues/account/24 hours and 1,000 globally/UTC day. Terminal/expired message payloads are cleared, with metadata scheduled for removal after 24 hours. These are code limits, not an accepted live retention policy.

Sessions expire after eight hours. Logout can leave only a SHA256 key hash and expiry for the session lifetime plus five minutes to prevent replay; scheduled cleanup removes expired tombstones. Active or unresolved provider billing must be cancelled/reconciled before account deletion. Actual database deletion still needs acceptance, and deleting active records does not prove erasure from backups or provider financial records. Their retention and deletion handling remain to be finalized.

Before real use

Use fictional data while these drafts and release gates remain unresolved. Actual operator/processors, security operations, backup/restore, rights-request contact and support procedures must be specified before launch. The full working draft is maintained in the project as PRIVACY_DRAFT.md.