Privacy

Five kinds of thing.

• What you type in. Your email address, and the tasks, notes, sets of hours, templates, repeating routines, inbox notes and blocked-out days you create. Plus your time zone, so your week is drawn in your own hours, and a log of the verbs you used — created, completed, cancelled, parked, pinned — with which surface each one came from: web, phone or Shortcut. That log stays with your tasks as their history.
• A copy of your calendar events, if you connect a calendar. Per event: its title and its description, the calendar it came from and that calendar’s name, its start and end time, whether it’s all-day, whether it counts as busy, and whether you marked it tentative or declined. Plus the calendar’s own ID for the event and when we last read it, which is how we notice one has been deleted. That’s the whole row.
• The plan we worked out. Once your tasks are fitted into the gaps, where each one landed is saved, so the app and the widget can draw your day without recomputing it.
• The credential for each calendar you connect, so it stays in sync without asking you to sign in again — plus the email address of that connected account, which is how the app labels it and tells two of them apart.
• Your subscription, if you have one. Which plan, whether it’s in a trial, running, cancelled or ended, the dates that go with that, when you were first charged and whether you’ve used your refund, plus Stripe’s reference numbers for you and your subscription, or Apple’s transaction number for a subscription bought in the iPhone app. Never a card number — that goes straight to Stripe or Apple and we never see it. Separately, whether you’ve asked for product emails, and when you last changed your answer.

An event’s description is kept so you can read it in YWGSD instead of opening your calendar app to find the dial-in. It’s stored as plain text and cut off at 2,000 characters, and it’s only ever shown back to you.

Some things we don’t keep. Event locations and guest lists never get stored — Google and iCloud hand them over anyway and they’re dropped on arrival, and with Outlook we don’t even ask. Nothing about your location is stored, and there’s no record of which pages you looked at. The surest way to protect something is not to hold it.

Mainly, working out when your tasks can happen and showing you the result. Your calendar tells the scheduler which hours are already taken, so it puts work in the gaps instead of on top of your meetings.

Separately, we count things across all accounts to see whether YWGSD is working: how many people sign up, start a free trial, add their first tasks, and subscribe, week by week. Those are totals only. They never name a person, and nobody reads your tasks to make them.

That’s all of it. There’s no profile built on the side, nothing is sold, and none of it goes into some other product.

Security procedures are in place to protect your data, and this is specifically what they are — along with what they don’t cover, because a list of only the good parts isn’t worth reading.

• The site is HTTPS only. Our host sends a two-year Strict-Transport-Security header, so once your browser has seen the site once it won’t try plain HTTP again. Requests to Google and Microsoft go to https:// addresses written into the code; iCloud discovery and Microsoft paging then follow the HTTPS addresses those servers hand back. The one leg that isn’t HTTPS is your sign-in email, which Supabase relays over an encrypted SMTP connection.
• Calendar credentials are encrypted before they’re stored. Every one — a Google refresh token, a Microsoft refresh token, an iCloud app password — is sealed with AES-256-GCM before it reaches the database, using a key that lives in the server’s environment and has never been in the database. Reading the row gives you ciphertext. So anyone who got at the database alone, including through a flaw that let a signed-in browser read its own row, couldn’t lift a working calendar credential out of it.
• Every row is tied to its owner by the database itself. Row-level security is on for all seventeen tables, and every rule ties the row to whoever owns it, so one customer’s query can’t return another’s row. Postgres enforces that, not application code that has to remember to check. A script runs the migrations against a throwaway Postgres and proves it — one account reaching for another’s rows in every one of those tables and getting nothing back — and it runs alongside the test suite.
• We hold no admin key that skips those rules. Most apps keep one. This one holds none anywhere, so the server acts as you, with your rights and nothing extra. A few narrow database functions are the exception. Three sign you up, delete your account, and file a capture from a Shortcut. The rest record what Stripe or Apple says about your subscription, and they refuse to run without a secret key only the server holds — so a signed-in browser can read its own subscription but can’t write itself one. Two more count: one the founding places that have gone, and one the weekly totals above. Both return numbers and nothing else.
• No password to steal. You sign in with a six-digit code we email you, on the web and on the phone, so there’s no YWGSD password to leak. The token behind the capture Shortcut is stored only as a SHA-256 hash — shown to you once, and not readable back out by us or anyone else.
• Credentials aren’t logged. Calendar tokens, app passwords and capture secrets travel in request bodies and Authorization headers, never in a web address, and no log line prints one. The logs that do exist are about billing: the type and ID of each event Stripe or Apple sends and what we did with it, and any error that comes back from Stripe, Apple or the email sender. One thing does pass through a URL by design: when you connect Google or Outlook, they hand us a short-lived, single-use authorization code in the address bar. That’s how OAuth works everywhere.
• Nothing in the page is watching you. No analytics script, no error-tracking service, no advertising pixel, no third-party script — so nothing on any page reports your activity to anyone, and there’s nothing to opt out of. The host that serves the pages sees the requests it has to serve, the way every web host does, and nothing here adds to that.
• The database provider encrypts what it stores at rest. Your tasks and the event copy sit in ordinary Postgres columns, protected by the owner-only rules above and by Supabase’s own at-rest encryption. That last part is their doing, not ours, and we’d rather say so than imply we encrypted it ourselves.
• Browsers are told to keep our pages out of frames. Every response carries X-Frame-Options: DENY, Content-Security-Policy: frame-ancestors 'none', X-Content-Type-Options: nosniff, a strict referrer policy, and a permissions policy switching off camera, microphone and location.

And what this isn’t. It isn’t end-to-end encrypted — the scheduler has to read your events to work out where your tasks fit, so the server sees them in the clear. Nobody has audited any of it: there’s no SOC 2 report, no ISO certification, no penetration test. And the encryption above protects your calendar credentials from the database, not from us — see below.

• Calendar events: the last 7 days and the next 120. Every sync rewrites that window and drops anything that’s gone from your calendar. Syncs happen while you’re using YWGSD, so if you stop using it, the last window we read stays put until you disconnect the calendar or delete your account.
• Everything you typed in: until you delete your account. Nothing expires on its own — a task you wrote down two years ago is still something you wrote down.
• Worth being straight about: sets of hours, templates, repeating rules and blocked-out days you can delete outright. A task you cancel and a thought you bin are marked done with rather than erased, so the text stays in the row — and the log of what you completed or cancelled stays either way. So deleting your account is the real delete.

• Delete everything, yourself, right now. Settings → Delete my account, on the web or in the iPhone app. Type the address on the account to confirm, then Delete everything. The account and every row belonging to it go in one pass — no queue, no grace period, no copy left in our database. We also ask Google to drop our permission at the same time; if Google can’t be reached right then the deletion still goes ahead, and you can remove the leftover entry yourself. A website subscription is cancelled at Stripe first, and Stripe keeps its own record of what you paid, under its own policy, which we can’t delete. An App Store subscription isn’t cancelled: Apple bills it, so cancel it in your iPhone’s Settings before you delete, or Apple keeps charging. Then we send one email to the address the account had, saying it’s done. That’s the last time we use it.
• Disconnect a calendar account from the Calendars screen. Our copy of every event it gave us goes with it, and so does the stored credential. Switching a single calendar off is a different control: that one stops it blocking your time, and its events clear on the next sync.
• Cut us off at the source, any time. Google: your Google account permissions. Microsoft: microsoft.com/consent — we can’t hand a Microsoft connection back for you, so that one’s yours to do. iCloud: delete the app password at appleid.apple.com. Any of those takes effect immediately and needs nothing from us.

What we can’t reach. If you’ve used the iPhone app it keeps a copy of your account on the device — tasks, notes, inbox, event titles and descriptions — so the app and the widget can draw without waiting for the network. Tapping Sign out clears it; if a session just expires instead, that copy sits there until you sign in and out again, or delete the app. Your phone’s own backup is yours, not ours. And there’s no export button yet: email us and we’ll put a copy together by hand, which may take a few days.

Nobody buys it. These companies handle parts of running the app, and see only what that takes:

• Supabase — holds your data, and runs sign-in.
• Vercel — runs the website and the app’s server, and sees the requests it serves.
• Resend (through Amazon SES) — carries the sign-in email: your address and the code. It also carries the few emails about your account: when a free trial starts, three days before it ends, when you cancel, and one confirming your account’s been deleted.
• Whichever calendar you connected — Google, Microsoft or Apple. We only ever read from them.
• Stripe, if you subscribe. It takes the payments, holds your card and whatever address it asks for, and sends receipts and failed-payment emails. Card details go straight to Stripe and never touch YWGSD.
• Apple, if you subscribe in the iPhone app. It takes the payment through your Apple Account and tells us the subscription’s status, renewals and refunds. We never see your payment details or your Apple Account’s email address.

We don’t hand any of them the right to use your data for their own ends. What each does under its own terms is theirs — your Google Calendar is still Google’s under Google’s policy, and a payment is Stripe’s or Apple’s under theirs. Beyond those companies, your data isn’t shared with anyone, and it never goes to advertisers or data brokers.

There’s no admin screen anywhere in the app — no page that lists users, reads someone’s tasks, or opens their calendar. But the database has an owner, and we can open it.

So, plainly: that access exists, it’s used to fix faults and to help when you ask, and it isn’t used to read your tasks for any other reason. Encrypting the calendar credentials stops anyone who has only the database — the key that opens them sits in the server environment, not in a table. It isn’t a wall against us, though, and it would be dishonest to sell it as one.

Connecting Google asks for three permissions on the consent screen:

• calendar.readonly — read your calendars and their events. This is the one the app needs.
• openid and email — your address, so the connection has a name on it and a second Google account can be told apart from the first.

• It’s read-only. YWGSD cannot create, change, move or delete anything in your Google Calendar, and it never tries to.
• Marking an event “free” inside YWGSD changes only how YWGSD schedules around it. The event in Google is untouched.
• Google returns more about an event than we keep — a location, the guest list. Those are dropped on arrival and never stored. The app does look at the guest list for one thing only: to find your own entry and see whether you accepted, and what it stores from that is two true-or-false flags. The description is kept, as HTML stripped back to plain text, so the app can show it to you.
• Your Google refresh token is encrypted before storage, exactly as described in How it’s protected.
• YWGSD’s use of information received from Google APIs follows the Google API Services User Data Policy, including its Limited Use requirements. Google user data is never used to develop, improve or train generalised or non-personalised AI or machine-learning models.

Connecting Outlook asks for four permissions: Calendars.Read, offline_access so the connection survives, and openid plus User.Read for the address it labels the connection with.

• It’s read-only. YWGSD cannot create, change, move or delete anything in your Outlook calendar.
• User.Read covers your basic Microsoft profile. The only thing the app takes from it is your email address, to label the connection — but the permission itself is broader than that, and Microsoft offers no narrower one.
• Microsoft’s refresh token is encrypted before storage. Revoke it whenever you like at microsoft.com/consent. We can’t hand a Microsoft connection back on your behalf — there’s no revoke in our code, and the permissions we ask for wouldn’t cover one — so that part is yours to do.

Apple publishes no calendar API and no “sign in and approve” flow, so an iCloud connection uses CalDAV with an app-specific password that you generate yourself at appleid.apple.com. This section exists because that’s a different bargain from the other two, and you should know what it is before you use it.

• The password is broader than the job. It authenticates to your iCloud account rather than to your calendars specifically — Apple offers no narrower scope.
• Read-only here is our own restraint, not Apple’s rule. The app only ever issues PROPFIND and REPORT — read-only verbs, nothing that could change anything. What it asks for is your calendars, their names and their events, plus the one account-level address CalDAV needs to find your calendars at all. Apple isn’t enforcing that boundary, though — we are.
• It’s encrypted before it’s stored, with a key that isn’t in the database, exactly like the Google and Microsoft tokens.
• Revoking it is done at Apple. Delete that app-specific password at appleid.apple.com and YWGSD immediately loses access. Disconnecting the calendar in YWGSD deletes our copy of the password as well.
• Your Apple ID email address is stored, because it’s also the username the connection signs in with.

• Sell your data, or share it with advertisers or data brokers.
• Use your calendar or tasks to train or improve any AI or machine-learning model.
• Show you advertising, or target any at you anywhere else.
• Judge your creditworthiness, or hand you to a lender.
• Build a database about you for anyone to query.
• Let another customer see your data. Postgres ties every row to its owner and checks it on every query. The database owner is the one exception, and it’s spelled out above.

Data is held in a Postgres database that Supabase runs, and the application runs on Vercel. Your email address also passes through the mail sender each time a sign-in code goes out. If you use the iPhone app, it keeps a copy of your account on the phone so the app and the widget can draw without waiting for the network — tapping Sign out clears it.

If we find out your data’s been exposed, we’ll email you at the address you sign in with, with what happened and what to do about it. A person writes and sends that — nothing here watches for it — so there’s no deadline being promised.

Questions about any of this go to hello@youwillgetstuffdone.com.