Help · Dibs.software
This is one thick help page with deep sections rather than a dozen thin ones, because a route that has nothing to say is worse than no route. Jump to what you need: how it works, why the no-names wall matters, what is built versus in development, the school-safe case, and the full FAQ.
On this page
The three-step flow, and the two database rules that make “first come, first served” actually true.
The no-names wall: what a sheet shows, what it deliberately does not, and why that is load-bearing when a child is involved.
The honest inventory: engine mechanics that exist, dibs.software surfaces in development, and the price that is not committed.
Parent-teacher slots and other student-facing sheets: the family wall, the consent chokepoint, and the no-names feed.
The questions people actually ask, answered plainly — cost, AI, differences from the sibling products, and whether you can use it today.
How calling dibs works
Step 1 — Somebody pins up a sheet of open times
A teacher, a coach, a club lead, whoever is handing out the thing everyone wants a piece of — they pin up the open times and how many people each one can take. That is the entire setup. Nothing to configure first, no builder to click past, just the times.
Step 2 — You call dibs on the one that suits you
Open the sheet, look at what is genuinely still going, and tap the time that works for you. You never catch sight of who took the rest, and none of them catch sight of you taking yours. One tap and it is yours — and if plans change, hand it back and it drops onto the sheet for the next person.
Step 3 — The storage layer, not the honour system, makes sure only one of you got it
Tapping runs two guards that live down in storage rather than up in code some later edit might skip: the live tally is pinned in place so it cannot slip, and a one-per-slot rule means a second grab on a taken time simply cannot be recorded. Whoever loses a photo-finish gets a tidy, try-again answer — not a Thursday booked twice over.
The two rules in step three are worth stating precisely, because they are the whole reason a dibs sheet is different from a paper one. First, a lock on the slot’s live-claim count is taken inside the claiming transaction, so the count cannot go stale between being read and being spent. Second, a partial-unique index on the resource and time window — restricted to live claims — means a second claim on an already-taken slot cannot be written at all. Both live in the database, not the app, so a future code path cannot forget them. Whoever loses a race gets a clean, retryable 409, never a silent double-claim.
The no-names design
A paper sheet often exposes names unnecessarily. Dibs is designed around a narrower view, but no Dibs sheet is available here. The existing family wall, roster stripping, and names-free feed are design boundaries, not verified Dibs deployments.
The reviewed shared scheduling core evaluates opaque references and a caller-supplied access condition. That does not establish a signed-token workflow or an enumeration-resistant Dibs route. The separate shared conference-booking route checks a recorded guardian relationship before recording a booking; its reachability does not prove a Dibs customer surface.
What is built, what is not
The no-double-claim partial-unique index, the capacity count under a lock, the overlap-rejection predicate. The broader Dibs family-wall, consent-gate, and feed mechanisms remain design boundaries. These are shared-source distinctions — not on any dibs.software deployment, because there is none.
The public claim sheet, the front door, the your-own-name branding overlay, and two-way calendar sync. These are the parts with the word dibs on them, and they are being built now.
dibs.software has no shipped product, so there is no price. The plan is one simple paid tier; the number is not set, and we would rather say that than print a figure we might change.
No live checkout, no card charged; any fee would be a computed, reserved line and Stripe is not enabled. No AI decides who gets a slot, and none is claimed. No FERPA, COPPA, SOC2, or VPAT certification is held.
The school-related design and its limits
Dibs is designed to limit a family view, apply appropriate consent handling, and avoid a public participant list. No Dibs school sheet is available through this site. The family wall, roster projection, and names-free feed are not claimed as verified Dibs mechanisms.
The separate shared conference-booking route checks a recorded guardian relationship before a booking write. That evidence is specific to that route. Its reminder endpoint returns a plan based on the supplied channel-purpose inputs; a queued-not-sent plan is neither a delivered notification nor proof of a durable queue.
This explanation creates no minor-data or consent procedure. The privacy and data page states the same design limit. A product enquiry does not open a school-data connection.
Full FAQ
Dibs.software is the design for a consumer first-come sign-up sheet: a simple way to describe open times and calling dibs on one. Shared scheduling decisions are built; the Dibs customer sheet is not available through this site. A product description is not an accepted booking.
The design addresses three familiar sheet problems: conflicting claims, unnecessary name lists, and distracting advertising. Actual shared code evaluates caller-supplied access, interval, and capacity inputs. The Dibs sheet is not available here, so the intended consumer experience is described as designed rather than demonstrated by a live customer action.
The Dibs view is designed to show open times and a count, without a browsable list of other people. No Dibs claim sheet is available here. The reviewed shared scheduling core requires an access predicate supplied by its caller; that computation does not establish a deployed Dibs family wall or a public roster projection. The existing school-related design remains a design boundary, not an invitation to provide a child’s information.
Nothing is on sale yet, so there is no price to quote and none is committed. The plan is one simple paid tier that lets you pin up a sheet, call dibs, and carry your own name and colours across it. We have not fixed the number, and we would rather admit that than print one we might move. This site has no live checkout and nothing on it touches a card.
Same booking core underneath, three separate products for three different moods. slotly.software is the flattest possible booking link — a slot, booked, no metaphor at all. penciled.software adds a pencil-it-in hold you can firm up later. dibs is the playful, consumer one: call dibs, first one there wins, aimed squarely at the person filling in a sheet rather than someone standing up a booking business. Each is its own brand with its own status told on its own page; naming them here is not a claim that any is live.
No Dibs school sheet is offered on this site. The design calls for a family wall, consent-aware handling, and no public participant list. In the separate shared conference-booking route, a recorded guardian relationship is checked before a booking is written. That scoped source evidence does not prove a Dibs roster-stripping route, a signed-token workflow, or a names-free subscription feed. Those broader Dibs mechanisms are described as designed, not verified as deployed. This page does not open a school-data workflow.
No AI scheduling action is offered through Dibs.software. This site does not choose a time, send a nudge, or provide a live claim sheet. The shared decision functions described here compute from supplied inputs; their existence is not a claim that an AI service is available.
No Dibs claim sheet or self-serve account is offered here. The shared core contains real access, interval, and capacity decision functions. Those pure computations do not themselves store a Dibs claim, publish a sheet, or send a reminder. The contact link opens an email enquiry; it does not reserve a product place, provision an account, or activate a feature.