privacy policy

jollygig has two products: team health, which surfaces honest signal about how a team is doing without exposing who said what, and scheduling, which turns three-point estimates into a spread of finish dates. both are built on one idea, to be honest about what we know and what we don't. this policy explains what data we collect, what we never collect, and what you can do about it.

the rule that comes first

survey responses are not tied to people. when a member answers the three-question check-in, the response is stored as { teamId, windowId, domain, emotion, intensity } — plus, only if your team uses bands, the band you picked for each dimension it uses (for example "1-3 years"). no name, no email, no user id, and no timestamp of its own: the only time on an answer is the id of the check-in window it belongs to, which is the date the check-in opened, the same for everyone on the team. like every database record, the document has a creation time in the database's own metadata; we never read it, export it, or show it, and nothing in the product joins it to anything. this is enforced in our database rules, not just in our application code. it is structurally impossible to query "what did alex say" because the data needed to answer that question does not exist in the response.

what we collect

account data

• your work email (used for sign-in via magic link).
• your display name and the role title you set during onboarding.
• for managers: the name of your team and any bands you configured.
• for members: which bands you place yourself in. the list is private to you; when you answer, the band goes onto your anonymous response, and bands are only ever shown in aggregate, and only once 5 people share one.

activity data (per user, private to that user)

• a participation ledger — "did i submit a response to this check-in" — stored against your account. this lets you see your own check-in history on /me. it is never joined to the response you submitted.
• your pause preferences, if you've opted to skip a week or longer.

aggregated team data (visible to managers)

• counts and percentages: how many people responded to each check-in, what share of them matched a given pattern, what the trend is over time.
• persona signals — named patterns that surface only when at least 5 people contributed.
• band breakdowns, but only when each band has 5 or more responses on its own — below that, the band simply isn't shown.

scheduling data (belongs to your organization)

• a scheduling workspace holds what you put in it: activity names and descriptions, three-point estimates, dependencies, the calendar, the correlation ticks you set, actual start and finish dates, and the forecasts we run from them. it belongs to your organization and is visible to the people you add to the workspace, as editors or viewers.
• we keep the newest 50 forecast runs of each workspace and drop older ones. the rest of a workspace stays until you delete it.
• no individual performance data is derived from it. jollygig does not compute or show estimate accuracy, speed or rankings for any person. forecasts and guidance describe activities and the plan.
• if you link a workspace to a team in team health, each forecast run saves a small snapshot of that team's aggregate signals: how many patterns are active now or emerging, an average intensity, and the top few domains. it is only saved when at least 5 people answered, it comes from the same anonymous aggregates as everything else, and it never contains responses or names.

things you send us

• feedback on scheduling, if you choose to send it: your message, an optional rating, your email and the workspace it came from.
• when an organization's owner cancels a plan, the reason they pick and any note they add. we read these to understand why people leave, and they are tied to the organization, not to anyone's answers.
• a small lifecycle log per organization and team: a trial started, a plan activated or canceled, the first check-in received, the first action plan created. it holds no user ids and no responses, and tells us whether the product is working.

billing data

• processed by stripe. we store only the brand, last four digits, and expiration of a card — never the full number, never the cvc.

what we never collect

• individual response content tied to a person, even by inference.
• a timestamp on survey answers: the only time on an answer is its check-in window (the database's own creation-time metadata is described under "the rule that comes first").
• free-text answers to surveys (the survey itself doesn't ask for any).
• per-person performance data derived from estimates or actuals in scheduling.
• browser fingerprints, ip-based tracking, or third-party advertising identifiers.
• contact lists, calendars, or any data from your devices or other tools beyond what you provide.

how the firewall is enforced

the firestore security rules block all client-side writes to the survey-response collection. the only writer is a single trusted server endpoint that constructs the response document field-by-field, with no user_id field present. an automated test (in our ci) reads back posted responses and asserts the absence of that field. if it ever fails, our ci goes red and the change does not ship.

who at jollygig can reach the database

jollygig's operators (the people who run the service) can technically reach the database, as with any hosted service. we never read the creation-time metadata, access is limited to the founder and logged by google cloud, and nothing in the product joins it to answers.

your rights

you can view your own data at any time, export it as json from /me/data, or delete your account yourself from the same page. deletion is immediate: there is no grace period and no undo. it clears your account record, your participation ledger, your pause preferences, your notifications, your action plans, your place in other workspaces, any invitations addressed to your email, and your team and organization memberships. a team you own where nobody else is, and a workspace you own alone, go with you, along with their answers and plans. scheduling feedback you sent keeps its words and rating but loses your id, your email and the workspace. if you are the only person in an organization you own, deleting your account also ends its subscription at once, without a refund. stripe keeps the customer record and its invoices for accounting; that is stripe's own retention, not something we can delete from here.

we won't delete a team, an organization or a workspace around other people. if you own one that others are in, the request is refused with a "transfer ownership first" message that names each one and links to where you hand it on. once ownership has moved, delete again.

scheduling workspaces belong to your organization, so work the rest of your organization still relies on stays for them when you leave. an owner can delete a workspace at any time: it disappears from the account immediately and stops counting toward the plan's limit, and a weekly clean-up erases what is left of it once it is 30 days old, so within about five weeks.

deletion does not remove your past survey responses — those are not tied to you, and removing aggregate signal would harm other members of your team. that's by design and not negotiable; it's the price of the firewall. the exception is a team you own alone: it goes whole, answers included.

retention

the totals of each check-in are kept. the individual anonymous answers behind them are deleted once their check-in is older than your team's retention period, which each team sets in team settings to between 6 and 60 months (the default is 24). scheduling content is kept until you delete it, apart from the forecast runs beyond the newest 50 in each workspace. your account record persists until you delete it. account deletion removes your account data immediately. our database is also backed up once a day and each backup is kept for 14 days, so deleted data has left those copies within 14 days. server logs are kept for 30 days.

third parties

customers who need a data processing addendum can read the template at /dpa; the full list of services we use is at /subprocessors.

• google cloud and firebase. firebase auth handles sign-in and sends the magic-link email; firestore stores your data and firebase app hosting runs the app. data is stored in google's nam5 multi-region (iowa and south carolina, usa); the app and its scheduled jobs run in us-central1 (iowa).
• stripe. processes payment and invoicing once you add a card. card details are entered with stripe and never reach our servers.
• mailchimp transactional (intuit mailchimp, usa). delivers the other emails we send you: invitations, check-in notices and summaries, and billing notices. it receives the recipient's address and the message itself, and we do not turn on open or click tracking.
• godaddy. runs dns for jollygig.com. it sees domain lookups, not your data.

the full list of subprocessors, including entity names, processing regions, and transfer mechanisms, is published at /subprocessors.

we do not sell, license, or otherwise share your data with anyone for marketing or advertising.

security incidents

if we ever discover a breach that affects your data, we will tell affected customers without undue delay, describe what happened in plain language, and say what we are doing about it.

contact

questions, concerns, or requests for deletion can go to help@jollygig.com. a person reads every message.