Privacy & data · Dibs.software
We schedule time. Here is exactly what that means for the data we hold.
A sign-up sheet has a narrow appetite by construction: it needs to know when a slot is open, who is entitled to claim it, and whether claiming it would break the one-winner rule. Most of what a school worries about handing to a vendor, a sheet never needs.
This page describes dibs.software and speaks for no other product. Every other product in the Stanley Studios family publishes its own policy on its own site.
What a claim record actually holds
Three kinds of data, and that is the list.
✓Times, and who may take them
The open times on a sheet, how many can take each one, and the claims against them: who claimed, for which slot, in which state (claimed, cancelled). That is the substance of the product — a sheet, and the rule about who may put a name on it.
✓The narrowest handle a claim needs
A claim references a person by the narrowest handle the sheet can work with. For a student-facing sheet that is a hash-verified guardian claim, resolved on the server, not a student identifier typed into a request. A sheet owns no census it does not need.
✓A roster, only when a school turns one on
If a school connects a roster to a sheet, every identity field on the roster route passes through a consent chokepoint first: a suppressed, lapsed, or do-not-publish student has their name masked and grade nulled at the server. The row still counts; only the identity is stripped.
What this product is not — said plainly
A sign-up sheet is not a roster you can browse, an ad network, or a camera.
✓No browsable list of who signed up
This is the whole point. A dibs sheet shows open times and how many are left, never a list of the people who claimed the other slots. A guardian’s identifier comes from a hash-verified server-side claim, never the request body, and a cross-family or cross-school request returns a uniform 404 — so the sheet cannot be used to enumerate who signed up.
✓No advertising profile, and sheet data is not a product we sell
We do not build an advertising or behavioural profile from a claim, and we do not sell or rent sheet data. There is no ad on a sheet and no third-party analytics or advertising script on this site.
✓No photos, no face matching, no gallery
dibs.software schedules time. Every surface is a slot, a claim, or an open count — never an image. There is no face matching in a sign-up sheet because there is nothing in one to match, and no photo store because it holds no photographs.
✓No automated decision about a child
Nothing here scores, ranks, or profiles a child. Calling dibs is a person tapping a slot; the software only makes sure two people cannot tap the same one. No model is trained on who claims what.
Minors
Minor scheduling data is consent-aware, access-controlled, and never public.
Three mechanisms carry that, and each runs on the server where a client request cannot reach it:
The consent chokepoint. Every identity field on a roster route passes through it. A suppressed, lapsed, or do-not-publish student has their name masked and grade nulled before the route returns — stripped, not hidden by a screen filter a crafted request could switch off. The row still counts toward the slot; only the identity goes.
The family wall. A guardian reaches their own claimed child and nothing else. The identifier is resolved from a hash-verified server-side claim rather than the request body, and anything outside that claim returns the same uniform 404 an unknown path returns — so the sheet gives an enumerating client no signal.
The feed carries no names. Any subscribable feed uses opaque labels: no student name, no teacher name, a non-PII handle rather than a real address. Subscribing to your slot cannot publish a list of names into whatever calendar app you use.
These are built in the shared engine. No dibs.software surface holds a child’s data today, because none is serving anyone yet.
Money, messages, and automation — what is off
Three places a product like this usually overreaches. All three are off.
✓No live checkout, and no committed price
There is no checkout on this site and no card data reaches us here. dibs.software has no shipped product and no committed price; any fee inside a future product would be a computed, reserved line, and the payment seam exists but Stripe is not enabled.
✓Reminders are opt-in, and nothing is sent today
Any reminder would be queued against the recipient’s own opt-in and suppressed without it. Nothing is delivered through this surface today, and consent can be withdrawn at any time.
✓No AI decides who gets a slot
Calling dibs is a person tapping a slot. No model is trained on who claims what, and no third-party service is called to decide anything. There is no AI claim on this product.
✓These pages set no cookie and run no client script
The page you are reading is a stateless server render. It sets no cookie, ships no client-side JavaScript, and calls no third-party analytics or advertising endpoint.
Asking us about data
A person answers, and the answer is specific.
If you want to know what a sheet holds — or want something corrected or removed — write to [email protected] and say which sheet it concerns. Because dibs.software is pre-launch and serving no one, in most cases the honest answer is that no sheet holds your data yet.