Privacy Policy

Last updated: 6 October 2026 · Effective: 30 September 2026

This Privacy Policy explains what personal information Dovetail Ventures LLC ("MostlyHostly", "we", "us"), a Texas limited liability company, collects, why, who we share it with, and what choices you have. It covers the website-hosting service at mostlyhostly.com and its subdomains, and the customer websites we host at *.mostlyhostly.site and on connected custom domains (together, the "Service"). It sits alongside our Terms of Service.

It is written for three audiences:

• Customers — people who create a MostlyHostly account and build a site.
• Site visitors — people who visit a website we host. See section 3.
• Our customers' customers — people who place an order through a site that uses our online-ordering add-on. See section 2.10.

Who is responsible for your data (controller / processor)

• For account, billing, and support information, and for the security and abuse logging described in section 2.5, MostlyHostly is the controller.
• For the content of a customer's site, information about that site's visitors, and orders placed through a customer's site, the customer who owns the site is the controller and MostlyHostly acts as their processor (service provider), handling that data only to run the Service and on the customer's instructions. Customers are responsible for having their own privacy notice where the law requires one.

If you are a customer and need a Data Processing Addendum for your own compliance, contact [email protected].

1. Quick summary

We do not use cookies or scripts to track visitors across sites, run advertising networks, sell personal information, or use your content or your customers' data to train our own models.

2. Information we collect

2.1 When you create an account

• Email address — your username and how we contact you.
• Password — stored only as a salted hash by our authentication system.
• Verification and account state — whether your email is confirmed, the verification token we email you, and your account status (active / flagged / suspended).
• Marketing opt-in — a yes/no flag from an unchecked box at signup. You can change it or unsubscribe at any time.
• Terms acceptance — the date you accepted the Terms and Privacy Policy, and which version.
• Access code, referral or partner code — we may require a code to register; we record which one you used. If a friend referred you, or you signed up through a partner's link, we record that, and whether the account later became a paying customer, so we can apply your discount and grant the referrer's or partner's reward.

2.2 When you build and manage a site

• Onboarding wizard answers — the information you type about your business: name, what it does, address, phone number, opening hours, menu or service list, events, and a free-text description of the style or "vibe" you want. We also keep your business type and how far through the wizard you got, to see where people get stuck.
• Business details you enter later — phone, email, address, hours (including holiday hours), social-media links, map position, languages, and similar settings.
• Customer reviews you add — if you use the reviews section, the reviewer's name and words, and optionally a star rating, date, where it was posted, and a link to the original. You choose what to publish; it is shown to anyone who views your site. You are the controller of this information and we store it for you in your site's repository (deleted with the site, see section 7). Reviews are never written by our AI tools.
• Uploads — files you add (logo, menu photos, room photos). These are stored on our server and committed into your site's git repository. A menu PDF is the exception: it is read once to fill in your menu, then deleted — it is not committed to your repository or served on your site.
• Repository content — everything in your site's git repository, including anything you or a tool you connect pushes to it, and the built website.
• Site settings — your subdomain, any custom domain you connect, plan and trial status, and activity logs (deploys, publishes, AI edits, reverts).
• Teammates — if you invite someone to a site, we store their email address, the role you give them, and the invitation, and we email them the invitation. Teammates can see the site's console pages that their role allows.
• Developer / AI-tool access — if you enable it: a git username we create for you, and metadata about the access tokens you generate (a short prefix and the issue date — never the full token or a password). If you connect an external AI tool over our connector, the OAuth client registration and the access/refresh tokens issued to it (see section 2.9).

Wizard answers and site content are visible to anyone who views your published site or its preview URL, because that is their purpose.

2.3 Payment information

Payments are processed by Stripe. You enter your card details on Stripe's hosted checkout — we never see or store your full card number. From Stripe we receive and store a customer identifier, a subscription identifier, and the status of your subscription (trialing, active, past due, cancelled), and we keep a record of your purchases (hosting, add-ons, credit packs) and any referral or partner reward credited to you. Stripe's own Privacy Policy governs how it handles your payment data.

2.4 AI features

The onboarding generator, the "describe a change" editor, the translator, and the "find my business online" and holiday-suggestion tools send the information you provide — your wizard answers, uploaded images and menu files, edit instructions, and the current files of your site — to our third-party AI provider (currently OpenAI, via its API) to produce the draft, edit, translation, or suggestion. The web-search tools also send the business name, address, and any website or social-media links you gave us, and the AI reads public web pages to find information, which it returns as suggestions for you to accept or ignore. We also keep a usage ledger: which type of job ran, the model used, token counts, and the approximate cost, so we can enforce your allowance.

We use the provider's API, not its consumer products. As of September 2026, OpenAI states that data submitted through its API is not used to train its models and is retained for up to 30 days for abuse and misuse monitoring, after which it is deleted, unless a longer period is required by law. Do not put confidential information into the AI tools.

2.5 Automated security and abuse logging

To keep an open signup form from being abused (fake accounts, subdomain squatting, running up AI cost), we record:

• your IP address and a timestamp against account actions — signup, site creation and deletion, custom-domain claims, and AI generations/edits — in an append-only event log;
• the result of a CAPTCHA / anti-bot challenge at signup, if enabled;
• rate-limit counters keyed to your IP address;
• abuse signals we derive from the above (for example, many sign-ups from one IP address, or many rapid deletions), which may lead to an account being flagged or suspended for manual review.

IP addresses in the event log are automatically erased after 90 days; the non-identifying event record is kept (see section 7).

We also scan sites for phishing, credential-harvesting, and impersonation, using the site's public content, and keep a record of what the scan flagged.

2.6 Support, forms, and other communications

If you email us or we email you about the Service, we keep that correspondence so we can follow up and keep a record. The same applies to:

• our contact form on mostlyhostly.com, which collects your name, email address, and message, plus your IP address and browser user-agent (to limit spam), and to which we reply with a signup code where one is available;
• our abuse-report form, which collects the address of the page you are reporting, the reason, your details, and — optionally — your email address, plus your IP address to limit spam. We may share a report with the site owner or a hosting/abuse contact where needed to act on it.

2.7 Google Business Profile (only if you ask us to help with reviews)

Today this is a manual arrangement, not a connection to your Google account. We do not use the Google Business Profile APIs, we hold no authorisation from Google for your profile, and nothing from your Google Business Profile appears on your website yet.

Your site's Reviews box explains how to add a MostlyHostly-run Google account ([email protected]) as a Manager on your own Google Business Profile. You do that yourself, in Google's own interface, and you can remove it there at any time (Business Profile → Users). It is your choice whether to do it at all.

The only thing we store is what you tell us in the console: that you have added us as a manager, the date you confirmed it, and an optional note you type (up to 500 characters). We do not copy your profile, your business information, or your reviews into our systems.

Where you do grant that manager access in Google, we use it only to prepare the review feature described below, and to look at the profile with you if you ask us for help. We do not change your business information, reply to reviews as you, or post anything to your profile, and we do not use anything we see there for advertising or to train any model.

Planned — showing reviews on your site. We intend to replace the manual arrangement above with a proper Connect Google action: you would authorise MostlyHostly through Google's own OAuth consent screen, using the Google Business Profile APIs and the business.manage scope, only to (a) list your business locations so you can pick the one this website represents, (b) read that location's reviews so you can choose which to feature, and (c) re-check the reviews you chose about once a day so edits show and deleted reviews drop off. For each review you chose to display we would store its Google review identifier and a cached copy of its star rating, text, reviewer display name, and date, plus a link back to the review on Google, and show it on your website with attribution to Google. We would store the Google authorisation (access and refresh tokens), delete it as soon as you disconnect, and read or change nothing else in your Google account. That feature is not available yet. We will update this policy before it is, and nothing described in this paragraph happens today.

2.8 Google Search Console (only if you connect it)

If your site has a custom domain, you can connect your Google account so we can prove to Google that you own the domain and tell Google where your sitemap is. You authorise this through Google's own OAuth consent screen, with the scopes webmasters (Search Console), siteverification (site ownership), and userinfo.email (which Google account you connected). We use that access only to:

• verify your site with Google Search Console (we add a verification tag to your site's settings);
• add your site to your Search Console and submit its sitemap, again each time you publish; and
• read your site's search performance (clicks, impressions, and top queries), which we show to you in the console when you open that page. We fetch it from Google each time and do not keep a copy.

We store the Google authorisation (a refresh token) encrypted, together with the connected account's email address and the state of the verification. We do not use Google data for advertising or to train any model, and we do not read any other part of your Google account. You can disconnect at any time from your site's settings; that deletes the stored authorisation. The verification tag stays in your site's settings until you remove it.

MostlyHostly's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements. Today that covers Google Search Console and site verification (section 2.8); it would cover the Google Business Profile APIs too if the review feature in section 2.7 ships.

2.9 AI assistants you connect (only if you connect one)

You can connect an AI assistant such as Claude or ChatGPT to your account through our connector. When you approve the connection on our consent screen, the assistant can list your sites, read their editable files, upload images, make edits, and publish, within your permissions. We store the assistant's OAuth client registration and its access and refresh tokens until you disconnect it. We record each edit it requests in our edit ledger, and changes are committed to your site's repository under an automation identity credited to you. What the assistant's provider does with the content it reads is governed by that provider's own terms and privacy policy, not ours.

2.10 Online ordering (only if you use the add-on)

If you turn on our online-ordering add-on, people visiting your site can place an order. You are the controller of this information and we process it for you. For each order we collect and store: the customer's name, phone number, and (optionally) email address; for delivery, the delivery address and map position they choose; any notes; the items and total; how they chose to pay; and, if they upload one, a payment-slip image, which can show banking references. We use it only to show the order to you and your team in the console, notify you of it, and let you manage it. Payment slips are kept in private storage — not in your website — and are shown only to signed-in members of your team. Orders are deleted when the site is deleted (see section 7). To limit abuse we use IP-based rate limits and a hidden anti-spam field on the order form, and we store the IP address and browser type the order was placed from; those two are erased from the order after 30 days. We also show you order statistics built from these orders — for example sales by day, best-selling items, how many customers ordered again, and a map of where deliveries went. The map groups delivery addresses into areas of roughly 450 metres rather than showing individual homes, and the statistics never show your customers' contact details.

If a customer gives an email address, we send them a receipt for their order in your business's name (at most a few to one address a day, to stop misuse). At checkout they can also tick an optional, unticked box to receive news and offers from you. Only if they tick it do we add them to your customer list, recording when they agreed, the exact wording, and which order it was (the same box on your booking and waiting-list forms adds people the same way — section 2.13). Every receipt to someone on the list carries an unsubscribe link; using it takes them off the list straight away (we keep a note that they unsubscribed, so they aren't added back by mistake). The list is yours to use for your own business only. We do not use it, or any of your customers' details, to market anything to them ourselves. It is deleted with your site. We do not receive or hold your customers' payments. They pay you directly — in cash, by a PromptPay QR code that credits your own account, or by card charged on your own Stripe account, in which case Stripe handles the card details and we only record whether the order was paid.

2.11 Site contact form (only if the site owner turns it on)

If a site owner switches on the contact form on their site, a visitor can send them a message through it. The site owner is the controller of this information and we process it for them. For each message we collect the name, email address, and message text the visitor types. We use it only to email it to the address the site owner has confirmed — with the visitor's address as the reply-to, so the owner can answer directly — and to show it to the owner and their team in the console for 30 days, in case an email goes astray. We do not send anything to the visitor, do not use the message for marketing, and do not read it except to investigate abuse. To limit abuse we use IP-based rate limits (the address is used only for that and is not stored with the message) and a hidden anti-spam field. We also email the owner's chosen address a one-time confirmation link before we send it any visitor messages.

2.12 Consulting (only if you hire us for it)

If you hire us for consulting (Terms section 17), we keep what you send us about the job — emails, the quote, invoices, and any content, files, or access details you share — and use it only to do that work, bill for it, and keep business records. Doing the work can mean seeing personal information held in your own systems (for example, customer details held by your old website or another provider). For that information you are the controller and we process it for you: we look at it only as far as the work needs, do not copy it anywhere except where the work requires (for example, the server you asked us to move it to), and do not keep it afterwards. Keep access details you share with us to what the job needs, and change them when we are done.

2.13 Bookings (only if the site owner turns it on)

If a site owner switches on online booking, a visitor can book a time on their site (a table, a class, an appointment). The site owner is the controller of this information and we process it for them. For each booking we collect the name, email address and phone number the visitor gives, the time and what was booked, the number of people if the owner asks for it, the visitor's answers to any questions the owner adds to the booking form, and any note the visitor adds. The owner writes those questions; we ask owners not to use them for health or other sensitive details. We also record the IP address and browser type used to make it, to limit abuse.

We use it to: take the booking and stop two people booking the same time; show it to the site owner and their team in the console and in the owner's private calendar feed; email the visitor a confirmation (with a calendar file), a reminder before the booking if the owner has turned reminders on, and a note if the booking is cancelled or a request is answered; and email the site owner about each new booking at the address they have confirmed (or not at all, if they turn that off). Each confirmation email carries a private link that lets the visitor see, change or cancel their own booking — it shows nothing else. We do not use booking details for marketing, do not share them with anyone but the site owner, and do not read them except to investigate abuse or keep the Service running. The visitor's name, email address, phone number, answers, note, IP address and browser type are erased 90 days after the booking time; the booking itself (what, when, how many) stays in the owner's records while the site exists.

Staff and rooms. A site owner may list the people or spaces guests book with (for example a stylist's first name). That name is shown to visitors on the booking page and in their emails; it is the owner's choice what to enter.

Deposits. If the site owner asks for a deposit, the guest pays the site owner directly, never MostlyHostly. By card, the payment is made on the owner's own Stripe account; we receive only whether it was paid, the amount and Stripe's payment reference — never card details. By PromptPay, the guest may upload a screenshot of their payment slip; we store it privately (never on the public website) so the owner can check it, and delete it with the rest of the guest's details 90 days after the booking, or when the site is deleted.

Google Calendar (only if the site owner connects it). The owner can connect their own Google Calendar. We then (a) ask Google only whether times are busy or free — we never read what is in their calendar — so busy times can't be booked, and (b) add each booking to that calendar as an event, including the guest's name, party size, phone, email, note and answers, so the owner sees it there. For a booking the owner has set up as a video call on Google Meet, Google makes a Meet link on that event; we store the link with the booking and send it to the guest once the booking is confirmed. Those events and calls live in the owner's Google account under Google's terms. The owner may also let a member of their staff connect that person's own Google Calendar (from the owner's console, or from a link the owner sends them). It works the same way for that person's bookings only: we check only when they are busy, add the bookings made with them to their calendar, and — unless switched off — email them about those bookings at the Google address they connected. Instead (or as well), the owner can give a staff member's own email address — any provider. We send it a confirmation link first and nothing else until it is clicked; after that, each booking with them arrives there as a calendar invite (with the guest's name, contact details, note and answers), updated or cancelled as the booking changes. The address is kept until the owner removes it or removes that staff member. The owner may also let a staff member manage their own availability — their hours and time off — through a private link sent to that address, or by signing in to MostlyHostly with it. That page shows the staff member the bookings made with them, including the guest's details, and nothing else of the owner's site or customers. Time off is kept until it has passed; any note on it is seen only by the owner and that staff member. The owner, or a staff member for themselves, can also paste the published link of any calendar (Outlook, Google, Apple and others can publish one). We read it every few minutes and use only when each event starts and ends — never its title, place or other details, which we do not store — so busy times can't be booked (the business's calendar blocks every booking; a staff member's blocks only theirs). The link is stored encrypted, is never shown again, and is deleted when it is removed or that staff member is removed. We store the connection's access token encrypted, and delete it when the owner disconnects. Our use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Waiting list. If a day is fully booked, a visitor can join that day's waiting list with their name, email address and phone number, the number of people, an optional time window and an optional note; we record the IP address used, to limit abuse. When a place frees up that day, we email everyone on the list whose time and group size fit, at the same time — the first to book gets it, and the email says so. Each email carries a link to leave the list. The site owner and their team see the list in the console and may contact the people on it about that day. Waiting-list entries are deleted 90 days after the day they are for.

News and offers. The booking and waiting-list forms have an optional, unticked box to receive news and offers from the business. Only if the visitor ticks it are they added to the business's customer list (section 2.10), with when they agreed, the exact wording, and whether it was a booking or the waiting list; every offer email carries an unsubscribe link. If the site owner turns on "Sorry we missed you", a visitor who ticked that box, was on a day's waiting list and didn't get a booking that day is sent the owner's offer the next morning, with a link to book; a booking made from that link shows the offer to the visitor, the owner and their team. Nobody who left the box unticked, or has unsubscribed, is sent it.

2.14 Visitor questions — "Ask us" (only if the site owner turns it on)

If a site owner switches on Ask us, their site shows an "Ask a question" button. The site owner is the controller of this information and we process it for them. We collect the question the visitor types, the language of the page, the time, and the IP address and browser type (to limit abuse). If the visitor chooses to leave an email address to hear back, we collect that too.

We use it to: answer the question automatically from the site's own published information or from answers the owner has written; if it can't be answered, send the question to the site owner (by email, or by WhatsApp if the owner has linked their number) so they can answer it; and, if the visitor left an email address, send them one email with the owner's answer — nothing else, and never marketing. The owner's answers (not the visitor's question as typed, and never the visitor's email) may be shown to other visitors and on a public FAQ page on the site.

To match a question to an answer that is worded differently, we may send the question text (never the visitor's email or IP address) to OpenAI to compute a numeric "embedding"; OpenAI processes it under its API terms and does not use it to train its models. The IP address and browser type are erased 30 days after the question; a visitor's email address is erased 30 days after the owner answers (or, for a question never answered, when the site is deleted). The question itself stays in the owner's records while the site exists, so the owner can see what visitors ask.

3. Information about visitors to sites we host

The shared web server that serves every hosted site writes a standard access log. For each request it records the visitor's IP address, the date and time, the host and path requested, the HTTP status, the referring URL, and the browser user-agent string. These raw logs are held on the server for up to about 45 days and then overwritten.

Periodically, an automated job reads the log and produces daily aggregate counts per site — number of page views, an approximate visitor count (based on the number of distinct IP addresses that day), the top referring websites, and the top pages. Only these aggregates are kept long-term (see section 7) and shown to the site owner in their console. The aggregates do not contain IP addresses or let the owner identify an individual visitor.

We do not set cookies on visitors, run client-side analytics or fingerprint scripts, or track visitors from one hosted site to another.

A generated site does not make third-party requests when a visitor loads it:

• Fonts. Web fonts are served by us, from the same address as the site itself (we download them from Google once, on our own server — never from a visitor's browser), so loading a page does not send the visitor's IP address to Google. The same is true of our marketing site.
• Maps. The map in a site's contact section is drawn in the visitor's browser from map tiles that we serve ourselves from tiles.mostlyhostly.site (on Cloudflare's infrastructure), so it does not contact Google. A "Directions" link opens Google Maps only if the visitor clicks it.

A site owner who adds their own code to a site (for example an embedded video or a third-party widget) is responsible for what that code loads and for telling their visitors.

If a visitor to a site with online ordering places an order, the details they submit are sent to our servers and stored for the site owner as described in section 2.10. If a visitor uses a site's contact form, the message they type is sent to our servers and forwarded to the site owner as described in section 2.11. If a visitor books a time, the details they give are handled as described in section 2.13. If a visitor picks a language on a multilingual site, the site remembers that in the browser's local storage (see section 4).

4. Cookies and local storage

We keep our use of cookies and browser storage to the minimum needed to make the Service work. We do not use tracking, analytics, advertising, or cross-site cookies anywhere.

• The admin console stores a login token and your unsaved wizard progress in your browser (local storage), so you stay signed in and don't lose your work. This is strictly necessary for the console to function; it is not shared with us beyond what the sign-in itself sends, and clearing it just signs you out. The signup form also loads Cloudflare's Turnstile anti-bot check, which Cloudflare runs under its own privacy terms.
• The marketing site (mostlyhostly.com) sets no cookies of its own.
• Sites we host (*.mostlyhostly.site and connected domains) set no cookies of their own. On a multilingual site, a small flag in the browser's local storage records that the visitor chose a language, so we don't redirect them again; it never leaves the visitor's device. A site's team members can also reveal a hidden "Manage" shortcut, which is remembered with a local-storage flag on their own device only.

5. How we use information, and our legal bases

The "legal basis" column uses GDPR / UK GDPR terminology for customers and visitors to whom those laws apply. In the United States, we process this data to provide the Service you have asked for and for our legitimate business interests in running it securely and sustainably.

We do not carry out automated decision-making that produces legal or similarly significant effects on you. Account flagging and suspension for suspected abuse are reviewed by a person before any lasting action.

6. Who we share information with

We are a small operation. We do not sell personal information or share it for advertising. We share data only with service providers that help us run the Service, and only what each needs for its role. All of them are based in, or process data in, the United States.

We may also disclose information:

• to comply with law, a court order, or a valid request from a public authority;
• to enforce our Terms or protect the rights, safety, and property of MostlyHostly, our customers, or the public (including sharing details of an abuse report with the reporter or a hosting/abuse contact);
• in connection with a merger, acquisition, or sale of assets, in which case we will require the recipient to honour this policy or notify you of any material change.

We update this section when the categories of providers change. A customer with a Data Processing Addendum can request the current list of named providers and will be told of changes as that addendum provides.

7. How long we keep information

8. Security

• The server accepts SSH connections by key only, with password login and root login disabled, a host firewall, and automatic security updates.
• Passwords are stored only as salted hashes. Secrets and API keys are held in restricted files, not in our code repository, and the credentials for connected Google accounts are stored encrypted.
• Site builds run in a locked-down, throwaway sandbox with no access to other customers' data, and every deploy is screened automatically before it goes live.
• Payment slips and other order data are kept in private storage and are shown only to signed-in members of the site's team.
• Off-site backups are encrypted.
• Access to the production server and database is limited to the operator.
• Backups exist to help us recover the Service; see the Terms — they are not a substitute for keeping your own copy of your repository.

No system is perfectly secure. If we become aware of a breach affecting your personal information we will notify you and any regulator as required by law.

9. International transfers

Our servers and our providers (section 6) are in the United States. If you use the Service from outside the US, your personal information is transferred to and processed in the US. Where the law requires a transfer safeguard (for example, the EU/UK Standard Contractual Clauses), we rely on the provider's incorporation of those clauses in its data processing terms.

10. Your rights

Depending on where you live, you may have some or all of these rights over your personal information:

• access — a copy of what we hold;
• rectification — correct what is wrong;
• erasure — delete it (subject to records we must keep);
• restriction and objection — limit or object to certain processing, including direct marketing (which you can always opt out of);
• portability — receive certain data in a portable format. You can already clone your site's git repository and export your traffic aggregates from the console at any time;
• withdraw consent — where we rely on consent, without affecting past processing;
• complain to a data protection authority.

To exercise a right, email [email protected]. We will respond within the time the law allows (generally one month for GDPR/UK GDPR requests). We may need to verify your identity.

If your request is about your data as a visitor to a site we host, as a customer who placed an order through one, or about data a customer holds about you, we will pass the request to the site owner, who is the controller for that data, and help them respond.

Complaints. If you are in the EEA or UK, you may lodge a complaint with your local data protection supervisory authority. If you are a California resident, the CCPA/CPRA gives you rights to know, delete, and correct your personal information and not to be discriminated against for exercising them; we do not sell or "share" personal information as those laws define it. Other US states may give you similar rights.

11. Children

The Service is not directed to children. You must be at least 18 to have an account. We do not knowingly collect personal information from children. Site owners are responsible for ensuring their own sites comply with any rules that apply to content directed at children.

12. Changes to this policy

We may update this policy. For material changes we will email your account address before the change takes effect. The "Last updated" date at the top always shows the current version. Continuing to use the Service after a change takes effect means you accept the updated policy.

13. Contact

• Privacy questions and requests: [email protected]
• Abuse reports: https://mostlyhostly.site/abuse/ or [email protected]
• Data controller of record: Dovetail Ventures LLC (Texas, USA), 5900 Balcones Dr, Ste 100, Austin, TX 78731-4298, USA.
• EU/UK representative or Data Protection Officer: not appointed — the Service is offered from the United States and we do not specifically target the EEA or UK.