Privacy Policy

1. Controller and contact

The legal controller has not been confirmed. The founder supplied the legal/privacy email below. Entity, registration, registered office, jurisdiction, any representative and any required/appointed Data Protection Officer remain pending. No other company is assumed to be responsible.

The intended operator is controller for account administration, security, voluntary consultations and its own product feedback. Processing real merchant personal data on a customer’s instructions could create a processor role in the future; that activity is not enabled by the synthetic Import Lab and would need a separate agreement.

2. Registration, identity and sessions

Lovable Cloud authentication stores account ID, registration email, password-verification material for email sign-in, provider identities/metadata and authentication timestamps/session information. Social sign-in can supply a name or avatar according to provider permissions; the app has no separate editable customer-profile table. Passwords are supplied to authentication, not stored in store-project fields.

Purpose: provide requested access, verify identity and secure accounts. Proposed lawful bases: steps at your request/performance of the eventual service agreement and proportionate legitimate interests in account security, subject to counsel approval and a documented balancing assessment. Necessary session storage is not marketing consent.

Recipients: Lovable Cloud and its verified subprocessors; Google or Lovable and the sign-in broker when you choose those providers. Browser session storage contains tokens and account metadata and is JavaScript-accessible. Preview may broker session storage to the editor. Provider retention, session lifetimes and international processing must be confirmed before launch.

3. Store concepts, versions and local drafts

Projects store owner ID, names, descriptions, configuration, status and timestamps; versions store owner/project references, configuration and notes. Unsaved drafts retain configuration and owner/project references on your device. Free-text fields may contain personal or confidential business information even though the plan itself is conceptual.

Purpose: maintain the concept you request, reopen it and preserve saved versions. Proposed basis: requested service/contract performance; security-related access checks may rely on assessed legitimate interests. Cloud records are owner-readable. Trusted internal roles do not by themselves grant access to unsubmitted drafts or versions; infrastructure maintenance access is a separate privileged boundary.

No project content is currently sent to an external AI model by the inspected Designer implementation. Curated images are bundled assets, not live rendering of each customer plan. Retention has no automatic application schedule and is subject to approved purpose-based criteria and eligible erasure. Local drafts have no configured expiry.

4. Voluntary public shares

Sharing stores owner/project/version references, a hashed unpredictable token, a safe immutable snapshot, enabled/revocation state and timestamps. A link exposes selected concept fields, not account email or internal notes. View budgets retain a global counter and existing-share counters, not visitor identities or IP addresses in those tables.

Purpose: provide the specific sharing action you request. Proposed basis: requested service; opt-in is a product disclosure control, not automatically the lawful basis for every processing purpose. Anyone holding the link receives its projection. Hosting may separately log requests; counter design is not a claim that hosting never receives an IP address.

Revocation stops new reads but does not delete the retained share or copies already obtained by recipients. Retention and erasure dependencies must be approved. Do not share sensitive information or third-party personal data without authority.

5. Consultation requests and product feedback

Consultations store your account and selected project/version references, submitted safe snapshot, name, email, optional phone, country/city, location availability, launch timeframe, optional budget/message, locale, consent timestamp/version and pipeline status. Feedback stores account ID, body, locale and timestamp. Authorized internal notes/audit entries can concern the request.

Purpose: respond to requested consultations, manage follow-up and assess supplied feedback. Proposed bases: pre-contract steps at your request and proportionate legitimate interests in handling feedback, subject to legal review. The consultation checkbox authorizes submission of the selected snapshot; it is not consent to marketing or disclosure of private future versions.

Recipients: authorized founder/admin staff and Cloud providers. There is no automatic commercial email delivery or external CRM integration in inspected code. Records lack an approved retention schedule or self-service deletion; closing a pipeline status does not erase them. The stored consultation privacy marker predates these drafts and does not establish acceptance of a new Privacy Policy.

6. Corporate enquiries and private investor preparation

Authenticated corporate contact requests store sender ID, name, organization, business email, a strategic/pilot/customer topic, language, consent version/time and review state. New submissions accept neither an investment topic nor a free-form message. Earlier interest records, including any optional message, remain preserved unchanged. You can read your own submissions; only explicitly authorized founders can review the queue. Admin-only access does not grant investment-material access. No customer concept is attached.

The separate consent permits review and response to your corporate enquiry, not marketing, a securities offering or an investment commitment. No automatic emails or CRM synchronization are enabled. Private founder-owned readiness drafts store preliminary financial assumptions and separate English/Bulgarian notes; minimal founder-only audit records contain actor, action, entity reference and time, not copies of contact text.

Cloud/hosting providers remain technical recipients. Lawful bases, retention criteria and erasure require operator and legal approval. Closing an inquiry does not delete it; no automatic expiry or whole-account erasure exists. These records must be included in the future approved deletion procedure. Use the confirmed privacy contact for rights requests.

7. Founder Studio and audit records

Authorized staff planning stores owner-linked requirements/content/status/dependencies, roadmap phases, decision titles/context/alternatives/reasons, language and timestamps. Some requirement and roadmap defaults are initialized automatically. Free text can contain personal or confidential information. Trusted roles identify permitted founder/admin accounts. Workspace audit records include actor, action, entity references, limited details and time. These records are not publicly readable.

Purpose: private development planning, controlled consultation operations and traceability/security. Proposed basis: assessed legitimate interests; a specific legal obligation applies only if identified, not by assumption. Internal staff see authorized planning/pipeline/audit data; customer access and unsubmitted customer-content access remain restricted.

Retention criteria must distinguish ordinary planning from security evidence and lawful holds. No automatic cleanup is implemented; display/query limits are not retention limits. Privileged erasure must address audit references without silently destroying accountability.

8. Co-Manager conversations and recommendations

Owner-linked records store synthetic store references, questions, rule-derived answers/evidence, recommendation snapshots, decisions/reasons, implementation/evaluation dates and outcomes. Settings include alert thresholds, advisory style, timezone/quiet hours and a scheduling preference; job rows contain leases, counters and error state.

Purpose: provide and preserve your requested simulated analysis and lifecycle decisions. Proposed basis: requested service, with assessed legitimate interests for integrity and abuse controls. Only your owner-scoped history is available to you; being a founder does not grant ordinary access to others’ histories.

Current audited explanations are deterministic and locally rule-derived; no external model call was found in these runtime paths. No merchant cross-sharing, benchmarking or model-training pipeline is enabled. Free-text questions can still reveal actual information; do not enter sensitive or unauthorized data. Schedules do not establish operational delivery. No automatic record-expiry job exists.

9. Retail Data Import Lab

The lab accepts exact approved synthetic CSV packs for products, transactions/lines, payment reconciliation, inventory, costs and suppliers. Files are selected on your device and submitted to the app server for admission/validation. Reports persist owner ID, fixture/scenario, transform-versioned source digest, derived financial/product/evidence results and timestamps; raw CSV files are not persisted by the application.

Purpose: demonstrate data validation and bounded recommendations, not process real merchant exports. Proposed basis: requested service. Account references remain personal data even though retail figures and supplier examples are synthetic. Reports are private owner-readable, client writes/deletes are prohibited and saves use authenticated server-derived evidence.

No live supplier/POS/payment connector or AI upload is enabled. Immutable report triggers need a dedicated authorized erasure exception before a whole-account deletion operation can work. Existing reports are not rewritten or deleted in this phase. Real business-data processing requires separate authorization, purpose/lawful-basis review and possibly a processor agreement.

10. Cookies, measurement and diagnostic logs

Functional browser storage covers sessions, language, drafts and sign-in destinations. The published host was observed setting deployment and bot-management cookies and injecting measurement/diagnostic scripts. The detailed storage draft distinguishes application storage from host controls; absence of Google/Meta app trackers is not absence of hosting telemetry.

Hosting scripts can send page/referrer and technical event data to same-origin collection endpoints; diagnostic hooks can receive errors. Provider payloads, storage defaults, recipients, retention and prior-consent controls require confirmation. Browser requests expose technical connection data to hosting. Proposed security-log legitimate interests and any optional-measurement consent must be separately assessed; no blanket exemption is asserted.

App-origin boundary diagnostics forward generic errors and route categories, rather than original error text, stacks or shared-link tokens. The updated application-controlled server console wrapper forwards a fixed error category and validated HTTP status, without retaining raw errors across requests. Independently injected hosting diagnostics, other provider sinks and historical logs remain separate and are not certified anonymized. Fonts are self-hosted in this preview. Earlier published observations included Google font requests; the latest clean published visit observed none. Published behavior can vary, and this phase did not deploy the app.

11. Recipients, transfers and backups

Verified runtime recipients include Lovable hosting/Cloud and selected authentication providers/broker. Infrastructure and authentication subprocessors, locations, transfer safeguards, support access and retention need contract/configuration evidence. A European database connection region is not proof that all processing remains in the EEA.

No current application call to Google Trends, myPOS, supplier systems or external AI models was found; planned adapters and configured secret names are not proof of a data transfer. Build-time imagery generation is distinct from runtime customer processing.

Lovable documents daily database backups retained for approximately fourteen days, excluding bucket files. This is provider documentation, not an inspected project backup inventory or an approved application retention promise. Erasure/restore procedures must prevent deleted data returning to service and explain any restricted backup retention.

12. Retention, security and your rights

No finalized retention periods are invented. Pending approval, criteria are necessity for the requested service, closure/withdrawal of a request, verified erasure, established statutory obligations and proportionate security evidence. Lack of a cleanup job means data does not automatically expire; an indefinite operational default is a launch gap, not an approved retention policy.

Implemented safeguards include authentication, owner-scoped row policies, server role checks, limited public projections, revocable hashed links, transactional evidence/quotas and server-only privileged writes. They reduce risks but are not an absolute confidentiality, security or availability guarantee. Provider administrative controls, incident response and legal retention still need review.

Where applicable, request access, correction, erasure, restriction, portability and objection; withdraw consent for any genuinely consent-based purpose without affecting prior lawful processing. You may complain to the competent data-protection authority and seek judicial remedies. The controller and jurisdiction must be confirmed; for Bulgarian matters the Commission for Personal Data Protection is a relevant authority, without limiting other competent authorities.

Send requests to the contact below from your registered address when possible. Verification should be proportionate; never send passwords, tokens or unnecessary identity documents. Explain any refusal, lawful retention and review/complaint options. GDPR generally requires a response within one month, with permitted extensions and timely explanation; this is a statutory rule, not a claim that an automated response system exists.