What Larkby knows about you.

Three things you give, two Larkby works out

You give a phone number, an email address, and the time you want to be woken. Larkby works out two more without asking for them. Your timezone is read from your browser, so the time you picked means the same thing wherever you are. Your country is taken from the number you typed rather than from the picker beside it — a +1 number with a Toronto area code is Canada even if the picker still says United States.

Four of those five are stored in Supabase. The phone number is not one of them: working out your country is the whole of what Larkby uses it for, and it is dropped as soon as that is done. There is no column for a phone number in any of Larkby’s tables, so there is nowhere for one to sit.

A message, and the voice that speaks it

None of this is required, and skipping it changes nothing about your wake-up call. You can write a short morning message — up to 200 characters — and choose the voice that speaks it. Both are stored against your account, and the words of the message are sent to xAI to be turned into speech. xAI is also the voice on the wake-up call itself, and what that means is set out below.

Your account also keeps a timestamp, set the first time your message is spoken back to you, because that is what puts the $9.99/mo button on your dashboard.

Larkby never asks you for anybody else’s details, and it keeps no phone number at all — not yours, and not anybody else’s.

A line for each call

Every wake-up call Larkby schedules gets a row of its own: the minute it is due, whether it is still waiting or finished, how many times it has been dialled, and the moment you spoke up to say you were awake. Larkby needs the count to know whether to ring again, and the confirmation to know the call did its job. Kept side by side over weeks, those rows are a record of which mornings you got up.

What was said on the call is not in them. The row holds the times and the outcome, and there is nowhere in it for anything else.

What a click records, and what a subscription would

Pressing the $9.99/mo button records a row saying you pressed it: which plan, the price you were shown, your country, and the advertisement recorded on your account, if there is one. It is written the moment you press, before anything else happens — because what Larkby is trying to learn at this stage is whether the price is worth paying, and that question is answered by the press rather than by the payment.

Nothing is charged, and nothing can be: live checkout is switched off, so the button acknowledges the press and stops there. You are not signed up to anything by pressing it.

If paid subscriptions do open later, taking one adds one further row: which plan, whether it is active, the amount charged, and the two identifiers Stripe uses to refer to you and to the subscription. Your card number is not among them — it is typed on Stripe’s own page and never reaches Larkby.

Google, a sign-in link, or a password

There are three ways in, and the card that books your free morning offers the first two, signing you up in the same step. With Google, it is Google that checks who you are, on Google’s own page, so your Google password never reaches Larkby and what comes back is the email address on that account. With a sign-in link, the link is emailed to the address you give, and asking for one on the login page creates an account for that address if it has none.

With a password, you choose it on the sign-up page and use it on the login page. There is no column for a password in any of Larkby’s own tables: Supabase holds it, in the auth tables it manages, and checks it when you sign in.

If you book with a sign-in link, the morning joins your account when you sign in with that address, through the link or with Google, or else when you next open your dashboard.

Three things there is nowhere to put

The company answerable for it

Larkby is made and run by Draft Labs Pte. Ltd. Everything above is that company’s to answer for: it decides what you are asked for and what that is used for, and it is who you are dealing with when you book a morning. Every other company named on this page is one your data passes through on its behalf, and the next section is the list of them.

Ask for a copy of what it holds, ask for it to be deleted, or ask a question about either, through the form at the foot of this page.

Everyone else it passes through

Supabase

The database, and the sign-in. Everything Larkby keeps is stored here; the session you hold once you are signed in is minted by Supabase, and a password, if you set one, sits in the auth tables it manages rather than in any table of Larkby’s own.

Twilio

The wake-up call, and the line it comes from. There is no phone number of yours to hand it: the one you type when you book decides your country and is then dropped, and Larkby has no column to keep it in. Larkby sends no text messages at all.

PostHog

Product analytics. On top of the events Larkby sends it, the library records clicks and the address of the page you are on, and it captures JavaScript errors.

xAI

The voice on the call. While a wake-up call is connected, everything said on it — your side and Larkby’s — is streamed live to xAI in both directions, because that is the only way anything can answer you. Your morning message goes the same way, on the call and again the moment you press play to hear it. Larkby passes that audio through and keeps none of it.

Railway

Hosting. Every request to Larkby passes through it.

Google

Sign-in, if you choose it over a password or a link by email. It happens on Google’s own page rather than on Larkby’s, so Google is told which of its accounts is signing in here and your Google password never reaches Larkby. What comes back is the email address on that account, which is what your mornings are stored against.

Resend

Email. Every sign-in link, new-account confirmation and password reset that Supabase sends you is delivered by Resend, so Resend receives your email address and the link. A request sent with the form below reaches the operator through Resend too, carrying your address and your message.

Stripe

Only if a paid subscription is ever taken. It receives your email address.

What an ad link carries

Arriving from an advertisement means the link carries tags — gclid, and the utm_ set. Larkby reads them out of the address and hands them to PostHog, which attaches them to analytics events so it can tell which advertisement brought you. That happens on whichever page you land on, this one included. Two copies are made in your browser as you arrive, both in sessionStorage: Larkby’s own, and PostHog’s, which is told to keep its store there rather than in the cookie and localStorage it would reach for by default. Both go when you close the tab.

A third is made if you sign up with Google. While Google checks who you are, the tags wait in a cookie with the rest of your sign-up, so the morning can be booked when you come back. The cookie is deleted as soon as you return, and it expires after 15 minutes if you never do.

A fourth outlasts all of those, and it is the one worth telling you about. When your morning is booked, the gclid and the campaign name are written onto your account and kept as long as the account is — they are covered by “Nothing expires on its own” below, and by the deletion form at the end of this page. Signing up with Google, or booking while signed in, only fills a tag that is still empty, and a booking with no ad writes nothing to either; the one time a newer advertisement replaces an older one is booking again with a sign-in link before you have signed in. They are kept so that Larkby can tell which advertisement led to somebody paying — which is the entire question the advertising is being run to answer, and the copies above are no use for it: none of them outlasts the visit it was made on.

A fifth is taken if you press the price. The row described under “If you press the price” above carries its own copy of the same two tags, so that a press can be matched to the advertisement that led to it without going back through your account. It is kept for as long as that row is, and the deletion form removes it with everything else.

A sixth goes back to your browser, and it is the fourth one returning. Opening your dashboard reads the gclid and the campaign name off your account and sends them to the page, so that the price there, which appears once you have played your first voice preview, can be credited to the advertisement that brought you. When the price comes into view, Larkby records that it was shown, and that record writes them into sessionStorage, in the entry every analytics event leaves behind — so the two copies you arrive with are not the only ones your browser ever holds. This one can turn up days after you arrived, and it goes when you close the tab it is in.

A seventh is written if you press the price. The press is recorded the same way, in an entry of its own beside the sixth that holds the same two tags, and it also goes when you close the tab.

What is left in your browser

• __Host-larkby_booking, a cookie set when you book with a sign-in link. It holds a random token and nothing about you, and it expires after 24 hours.
• __Host-larkby_signup, a cookie set when you continue with Google. It holds your wake time, timezone and country, which version of the page you signed up on, a random code for that one attempt, and the advertising tags if you arrived from an ad. It is deleted when you come back from Google, and it expires after 15 minutes if you never do.
• __Host-larkby_just_booked or __Host-larkby_booking_failed, a cookie set when you come back from signing up with Google, or book while already signed in, to tell your dashboard whether the morning was booked. It holds a random id and nothing about you. Your dashboard reads it once and deletes it, and it expires after 10 minutes either way.
• Supabase’s sign-in cookie, set once you sign in. It is written to last 400 days rather than to the end of the browser session, and scripts on this site can read it.
• PostHog’s own store — the identifier it gives this browser, and the properties it stamps on what it sends. Larkby sets that store to sessionStorage rather than the cookie and localStorage PostHog would use by default, so it goes when you close the tab.
• The advertising tags above, in sessionStorage. Larkby’s copy and PostHog’s are made when you arrive; a third is made when the price on your dashboard comes into view, and a fourth if you press it. Those two are analytics: entries, listed below. All four go when you close the tab.
• One analytics: entry in sessionStorage per analytics event, holding everything sent with that event. They go when you close the tab.
• larkby:landing_engaged, set in sessionStorage on the home page once you have stayed or scrolled, so one visit is not counted twice. It goes when you close the tab.
• larkby:account_created:…, set in sessionStorage when you continue with Google, so one sign-up is not counted twice. What follows the name is the random code for that attempt, and nothing about you. It goes when you close the tab.
• larkby:pay_intent, set in sessionStorage when you ask about the every-morning plan, so one click on that offer is not counted twice. It goes when you close the tab.
• larkby:booking_confirmed:…, set in sessionStorage so one booking is not counted twice. When your dashboard sets it, what follows the name is a random id and nothing about you. When the page you reach after asking for a sign-in link sets it, your wake time, your timezone and your country are written into the name, and scripts on this site can read them. It goes when you close the tab.

Nothing expires on its own

Larkby deletes nothing on a schedule. There is no expiry job and no retention window: what is stored stays stored until someone asks for it to be removed, and the removal is done by hand. That is about the rows Larkby keeps — most of what your browser holds goes when you close the tab, as the list above says. That is the whole of it, and it is why the form below exists.

Ask for your data, or its deletion