What we hold, and what we don't

Who this covers

Two different sets of people appear in this policy, and the difference decides who answers for what.

Customers

Businesses who have, or are asking for, a website with us. For your information we are the responsible party: we decide why we hold it and we answer for it.

Visitors to a customer's site

People who browse, enquire or buy on a site we host for somebody else. For their information our customer is the responsible party and we act on that customer's instructions — we store it, keep it safe, and do not use it for our own purposes. If you filled in a form on a customer's site, ask that business first; we will help them action your request.

This policy covers the platform, this marketing site and the customer console. Each site published on the platform is otherwise governed by its own owner's privacy policy.

What we collect from you

When you ask for access

The access form takes your name and email address, and optionally your business name, your domain, which AI assistant you use and a description of what you want to build. We also record the time and the IP address the request came from, because that is how the spam screening works. A person reads it and replies.

When you have an account

We hold your email address, the sites you own and your plan. Signing in to the console uses a link emailed to you rather than a password: the link is good for 30 minutes and works once. After that your browser holds a session cookie for seven days.

Your connector token

The personal token your AI assistant uses to reach your site is recorded so we can check it. You can revoke it and mint a new one yourself, from the console, at any time — the old one stops working immediately.

Integration credentials you choose to add

If you sell through PayFast, we store the merchant credentials you give us so that a checkout can be signed. They are held server-side and are sent only to PayFast, at the moment of a payment. The same applies to any Google Analytics, Maps or Ads key you add: held for your site, used on your site, nowhere else.

When you email us

We keep the correspondence, because otherwise we cannot help you the second time you write.

What is collected on the sites we host

Visitor counting

Sites can count visitors without cookies, and that is the default. For each pageview we record the path and the referring website. To estimate how many different people visited, we compute a one-way hash of the visitor's IP address and browser, mixed with a secret and with today's date. The raw IP address is never written down. The hash sits in that day's totals file and cannot be matched against any other day, because tomorrow's recipe is different. Nothing is stored on the visitor's device, nothing follows them to another website, and browsers sending a Do-Not-Track signal are not counted at all.

Form submissions

When someone fills in a form on a customer's site we store the fields that form asks for, the time, and the sender's IP address, which is used for rate limiting and spam screening. The record is stored with that customer's site and is emailed onward to the address the customer nominated. They can read it, export it as a spreadsheet, mark it read, spam or archived, and reply to it — the reply goes through our mail provider with their address on it.

Deleting one submission erases it. Not archived, not hidden — the stored record and its read/reply history are removed. Ask your AI to delete it, or do it from the console. That is what an erasure request from one of your visitors runs through.

Mailing-list signups

A site can offer a signup box. It collects the email address, removes duplicates, and exports to a spreadsheet for the site owner. Removing an address erases every sign-up record it appears in — an unsubscribe here is a deletion, not a flag. One honest limitation remains: the list is single opt-in, so there is no confirmation email yet, and the site owner is responsible for only mailing addresses genuinely offered to them.

Orders, on the Store plan

For a purchase we record the product, the amount, the order status, whether it was a live or sandbox payment, and the buyer's IP address at checkout. When PayFast confirms the payment, the confirmation it sends us also carries the buyer's name and email address, and that is stored on the order record so the seller knows who bought. We also keep a log of those confirmation messages, which is what lets us prove what a gateway told us if a payment is ever disputed. Card details never reach our servers — the card is entered at PayFast.

Photographs and files

Images uploaded to a site are re-encoded before they are stored, which strips the camera and location metadata most phones embed. That is a default, not an option. The original filename is kept as part of the stored name, so avoid putting somebody's name in a file name if you would not put it on the page.

Server logs

Like any web service, our servers keep operational logs to diagnose faults and to spot abuse. Those records can incidentally include IP addresses, the pages requested, and account email addresses where an action was taken by a signed-in customer. They are used for running and securing the service, and for nothing else.

Your AI assistant and your data

This is the part that is genuinely different here, so it gets its own section rather than a footnote.

The platform makes no calls to any AI provider. We do not relay your content to a model, and nothing on this platform is used to train anything — not ours, not anybody's.

But your assistant is not us. When you connect an AI assistant and grant it access, it can read your site and the data attached to it — including your form submissions and your order records, which contain other people's personal information. When you ask it to read them, that content goes to your AI provider under your own subscription and your own agreement with them.

That is a real consequence and worth thinking about before you ask your assistant to summarise your inbox. Two things make it manageable: the access is scoped to your own sites and plan and nothing else, and you can revoke the token at any time from the console. As the responsible party for your visitors' information, the decision to hand it to an assistant is yours to make deliberately.

Cookies

The complete list of what we set, by default, is short:

• A console session cookie, once you sign in to your dashboard. It is HttpOnly, restricted to same-site use, and lasts seven days. Without it you cannot stay signed in, so there is nothing to consent to.

That is the list. No analytics cookie, no advertising cookie, and nothing fetched from another company while a visitor is simply reading a published site. That is why the sites we build do not need a cookie banner.

Where a page shows a map or a video, what loads is a placeholder, not the embed. OpenStreetMap and YouTube are contacted the moment a visitor presses the button — and the button says so before they press it. A visitor who never presses it never meets them.

One exception, and it is the customer's choice: a customer can add their own Google Analytics, Google Maps or Google Ads keys. Those do set cookies and send data to Google, so the platform switches on a consent banner automatically the moment one is added.

Who else touches it

We do not sell personal information and we do not share it for anyone else's marketing. The only third parties involved are the ones needed to run the service:

• Hostinger — our servers and our outbound email. They hold the data at rest and carry the messages we send, including sign-in links and form notifications.
• PayFast — payments, for customers on the Store plan. They take the buyer's card details directly; we never see them.
• Let's Encrypt — the HTTPS certificates. They see domain names, not people.
• Google — only if a customer has added their own Analytics, Maps or Ads keys, and only on that customer's site.
• Your own AI provider — whichever assistant you connect, when you ask it to look at something. See above; that relationship is yours, not ours.

We will also hand over information where the law compels us to. If that happens and we are permitted to tell you, we will.

If the business is ever sold or merged, personal information may transfer with it. Any successor takes it subject to this policy.

Where it lives

Our servers and our mail relay are in Frankfurt, Germany. The company and the people are in South Africa, so your information crosses a border to be stored.

POPIA permits this where the destination offers comparable protection. Germany is subject to the EU's General Data Protection Regulation, which is the strictest regime in common use — in practice the information is held under stronger rules there than in most alternatives. Payments are processed by PayFast in South Africa. We tell you because you are entitled to know, not because it is a problem.

How long we keep it

Sign-in links

30 minutes, and they stop working after one use.

Console sessions

Seven days, then you sign in again.

Form submissions, mailing-list addresses and orders

Kept with the site. These are the customer's business records, so the customer decides when they go — there is no automatic expiry. Deleting the site removes them all, and an individual record can be erased on its own, by the customer, at any time.

Visitor counts

Kept as daily totals files. They hold no name, no address and no reversible identifier, and cannot be linked across days.

Access requests and support email

Kept while we are still talking, and removed on request.

Server logs

Kept for operational and security purposes and rotated in the ordinary course.

Two honest caveats about deletion on this platform, because "deleted" is not always instant:

• Every publish is kept as an unchangeable release, so that a site can be rolled back. If a page contained personal information when it was published, that page still exists inside those older releases. Deleting the site removes them; if you need a specific release purged sooner, ask and we will do it by hand.
• A deleted site is retained briefly before it is purged, so that an accidental deletion can be undone by our staff. It stops serving to the public immediately.

What you are responsible for

If you run a site on this platform, some of this is yours rather than ours. You are the responsible party for the people who use your site, which means:

• publishing your own privacy notice, describing what your forms collect and why;
• only mailing people who genuinely gave you their address, and giving them a way to stop;
• answering your own visitors' access and deletion requests — the tools to do it are in your console and available to your assistant, and we will help if you get stuck;
• deciding, deliberately, whether to let your AI assistant read information your visitors gave you.

Your rights

Under the Protection of Personal Information Act you may ask us what we hold about you, have it corrected, have it deleted or destroyed, object to how we are using it, withdraw a consent you gave, and complain if you are unhappy with the answer. You do not need a reason and there is no charge for asking. We may need to confirm who you are before we act, so that we are not handing your information to somebody else.

Ask through the contact form and a person will handle it. If we get it wrong you can take it to the Information Regulator of South Africa, who supervises us. If you are in the European Union, the equivalent rights under the GDPR apply and you may complain to your local supervisory authority.

We do not make decisions about anybody by automated means alone. Spam screening and rate limiting decide whether a single message is accepted, not anything about a person.

We do not ask for special categories of information — health, religion, politics, trade union membership, biometrics or criminal history — and the platform has no field for them. The service is for businesses and is not directed at children; we do not knowingly open accounts for anyone under 18.

How it is protected

• Everything travels over HTTPS, on every site, from the moment it exists.
• Published sites are static files. No customer code runs when a visitor arrives, which removes most of what usually goes wrong on a website.
• Payment credentials are held server-side and never appear in a page, a draft or a chat.
• An AI assistant's access is scoped to its own customer's sites and plan, and enforced on the server rather than requested politely.
• Uploads are re-encoded before storage; forms are rate-limited and spam-screened.
• Sign-in is by single-use emailed link; session cookies are HttpOnly and same-site.

Nobody can promise a system will never be breached. If personal information in our care is compromised, we will notify the Information Regulator and the people affected as soon as we reasonably can, in enough detail for them to protect themselves — and we will tell you what actually happened rather than a sanitised version.

Changes to this policy

When this page changes, the date at the top changes with it, and we will tell customers by email before a material change takes effect. Because this site runs on our own platform, every previous version is preserved as a release — so if you want to know what it said before, we can show you rather than describe it.

Getting hold of us

The quickest route is the contact form. It reaches a person, and it is the same forms service described above — so you can watch exactly what happens to what you send.

plain-English policy · 28 August 2026 · see also the terms of service