Privacy Policy

You are our customer. We are the controller of your own details - your name, your practice, your email, your country, what you pay and how you use the product.

Your clients are yours. Everything you record about the people you coach - their names, their session notes, their questionnaire answers, their documents - is theirs and you are its controller. We are your processor. We do not decide what is collected, we do not use it for our own purposes, and we do not read it.

Almost every question about this policy resolves once you know which of the two you are asking about.

We do not sell your information, we do not share it with advertisers, and there is no advertising or analytics tracker on the pages you sign in to.

If you use the "Ask about any feature" box on our website, the question you type is sent to Anthropic, our AI provider, to generate the answer. It is not stored with your identity, it is not used to train any model, and anything that looks like an email address or a number is removed before it leaves.

The signup check uses these outside services, for our own purpose and not on your clients' data: rdap.org and crt.sh (your email domain only - its registration date and its certificate records), Anthropic (your email domain, the public text of its website and its DNS records, to judge whether it belongs to a coaching practice), and, only where we have switched them on, Have I Been Pwned and GitHub (your email address - which public breaches and how many public code commits it appears in) and ipinfo.io (your IP address - whether it belongs to a data centre or VPN). They are not on the sub-processor list because they never touch your clients' records.

Exactly one thing: running the features you asked for. Storing a session note, generating an invoice PDF, sending a booking confirmation, producing a summary when you have turned that on.

It is not used to improve our product, it is not aggregated into anything we publish, it is not shown to our staff, and it is not used to train any model - ours or a provider’s.

A small, named set of sub-processors, each doing one job. The current list - with what each one does, where it is, and the safeguard that covers the transfer - is at /subprocessors, and we will tell you before we add one.

If you connect a calendar - Google Calendar, Microsoft Outlook or an Apple (CalDAV) calendar - we use it for two things only: to know when you are busy, so that a client cannot book over a time you already have, and to put the sessions you schedule here into that calendar. Nothing else.

What we read. The list of calendars on the account, so that you can choose which one to use, and the busy times of the calendar you chose. Busy times are stored as start and end times only - bare blocks, replaced in full at every refresh. For Google Calendar we ask Google’s free/busy interface, which returns those times and nothing else: we do not read the titles, descriptions, attendees or locations of your own events.

What we write. One calendar event for each session you schedule, carrying the session title, the client’s name in its description, the client as an attendee so that they receive the invitation, and a video-meeting link where you have chosen that provider. We keep that event in step with the session - deleting it when the session is cancelled - and we never change or remove an event we did not create.

What we keep. The email address of the connected account, the identifier and name of the calendar you chose, the access and refresh tokens the provider issued so that syncing does not ask you to sign in every time, when we last synced and whether it failed, and the busy blocks. All of it lives in our database, which is encrypted at rest, and none of it is readable from our administration console.

What we do not do. Calendar data is not used for anything but the two purposes above. It is not shared with anyone beyond the sub-processors that host the platform, not sold, not used for advertising, not read by any person at the platform, and never sent to any AI or machine-learning service, ours or a third party’s - it never reaches the code path that calls one, so there is nothing to train on.

Disconnecting. Disconnect from Settings and we delete the tokens and every busy block at once; the events we wrote to your calendar stay, because they are yours. For a Google account you can also withdraw our access at myaccount.google.com/permissions, which invalidates the tokens we hold.

Our use of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements.

The platform is a Florida limited liability company, established in the United States and hosted in US regions. If you are in the EU, the EEA or the UK, your data and your clients’ data is therefore transferred outside your own country.

That transfer relies on the European Commission’s Standard Contractual Clauses (and the UK Addendum where the UK GDPR applies), together with a transfer impact assessment covering US government access. Encryption in transit and at rest is applied throughout. A copy of the clauses forms part of our Data Processing Agreement.

Closure is not immediate darkness. We write to you at closure, at 60 days, and 7 days before the data is destroyed, and you can sign in and read everything at any point in between; exporting needs an active paid plan.

If you are in the EU, the EEA or the UK, you have the right to access, rectify, erase, restrict and port your data, to object to processing based on legitimate interests, and to complain to your own supervisory authority.

If you are in the United States, the state you live in may give you the right to know what we hold, to have it deleted or corrected, to a portable copy, and to opt out of sale or of targeted advertising. We do not sell personal information and we do not engage in targeted advertising, so the last of those has nothing to act on. You may appeal a refusal, and we will tell you how when we refuse.

A request from one of your clients comes to you, not to us. You are their controller and only you can answer it - we do not know who they are. If one reaches us we route it to you, record that we did, and go no further.

Our administration console reads two things: your account row, and a nightly table of integers - how many clients, how many sessions, how many bytes. It is structurally incapable of reading a client’s record: the database client it holds refuses every row-level read of a coachee-owned table, and the build fails if any administration screen imports the unrestricted one.

There is no impersonation. No administrator can sign in as you, at any privilege level, for any reason.

We are not claiming your data is unreadable to us. We operate the database and hold its credentials; only encryption under a key you alone held could make that untrue, and it would break PDF generation, AI features and email. What we claim is narrower and true: the console cannot emit personal data, and direct database access is a break-glass procedure that requires a ticket, a stated reason, a time box and an entry in an access register.

Encryption in transit and at rest; tenant scoping enforced at the database client so one account’s query cannot return another’s row; multi-factor authentication required for every administrator and a fresh code re-entered before every irreversible action; an audit log with a mandatory reason on every administrative act; backups with periodic restore tests and an integrity sample of object storage.

The full technical and organisational measures are Annex II of the Data Processing Agreement, which we will give you on request.

Where we are your processor we will tell you without undue delay after becoming aware of a personal-data breach, with what we know and what we are doing, so that you can meet your own 72-hour duty. We do not notify your clients - you are their controller and that contact is yours to make.

Where we are the controller - a breach of your own account details - we notify the relevant authority and you, as the law requires.

Strictly necessary cookies only: one to keep you signed in, one for CSRF protection, and a first-party cookie recording a referral code if you arrived through a referral link. No analytics, no advertising, no third-party tracking, and therefore no consent banner - there is nothing to consent to.

If we ever add analytics to a marketing page, this section changes and a consent mechanism appears with it.

The software is for professional coaches and is not directed at children. If you coach minors, you are responsible for the consents that requires in your own jurisdiction.

As a controller not established in the EU or the UK we appoint representatives under Article 27 of the GDPR and the UK GDPR. Their names and addresses will be published here. Until they are appointed we do not sell to consumers in those markets.

The version of this policy is printed at the top of the page. Material changes are notified before they take effect. Everything reaches us through the in-app support form, which creates a ticket with a response target rather than landing in an inbox nobody owns.