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.
Why you never see other names
On a paper sign-up sheet, everyone who looks can read every name already on it. That is the single thing dibs refuses to reproduce. A dibs sheet shows you the times that are still open and an honest count of what is left, and nothing about the people who claimed the other slots — not their names, not that they claimed at all.
There is no browsable roster because there is no roster to browse. When a sheet touches student data, a guardian reaches only their own child; the identifier comes from a hash-verified server-side claim rather than anything typed into a request; and a cross-family or cross-school request returns the same uniform 404 an unknown page returns. The sheet cannot be used as an oracle to enumerate who signed up. This wall is built in the shared engine; the dibs.software sheet that draws it is in development.
What is built, what is not
The no-double-claim partial-unique index, the capacity count under a lock, the overlap-rejection predicate, the family wall, the consent chokepoint, and the opaque-label feed. Built and exercised in the shared core this whole family sits on — not on any dibs.software deployment, because there is none.
The public claim sheet, the free 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 a free front door and a small paid tier; the numbers are 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.
Using it for a school sheet
The most common school use is a teacher posting parent-teacher conference slots. It is also the case that touches a child’s data, so the same three mechanisms from the home page apply, and they run on the server:
The family wall means a guardian only ever reaches their own child, and one family never sees another family’s name. The consent chokepoint strips a suppressed student’s name and grade at the server when a roster is read, and the row still counts. The calendar feed carries opaque labels only, so subscribing to your slot never publishes a list of names into your calendar app.
None of this holds a child’s data on a dibs.software surface today, because no dibs.software surface is serving anyone yet. It describes how the sheet is being built, on walls that already exist in the shared engine. If a data or consent question is what stands between you and trying it, the privacy and data page is the short version, and [email protected] reaches a person.
Full FAQ
It is a sign-up sheet where the first person to grab a time actually keeps it — the parent-teacher slot, the microscope everyone wants on Thursday, the help-desk hour before a deadline — except the “first come, first served” bit is settled down in storage rather than left to whoever happens to be holding the pen.
Three things a paper or spreadsheet version fumbles. It will not let a slot land on two people — that is a rule the storage layer keeps, not an honour code. It will not hand you a scroll of who else signed up — your view is the open times and how many remain, and nothing about anyone else. And it will not flash an ad at the parent trying to grab a spot. The warm, familiar feel of a sign-up sheet, minus the three ways a real one lets you down.
No, by design. Your view is the open times and an honest count of what is left — never a run of names. Where a sheet touches a child, that wall is load-bearing: a guardian only ever reaches their own child, the child is pinned down by a signed token settled on the server rather than anything the browser sent up, and a reach toward another family comes back looking just like a page that never existed. There is no seam to pry the sheet open and read off who signed up.
Nothing is on sale yet, so there is no price to quote and none is committed. The plan is a front door that is genuinely free — free to pin up a sheet and free to call dibs — with a modest paid step above it for folks who want their own name and colours across the sheet. We have not fixed the numbers, 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.
That is the exact case the wall was drawn around. A guardian only ever reaches their own child, and one family is never shown another family. Where a class list is read, each name passes a consent gate on the server first: a child marked private has their name and grade taken out before the page comes back — genuinely removed, not merely tucked behind a screen toggle a doctored request could flip — while their place still counts. Any feed you subscribe to shows blank stand-in labels: no child, no teacher, just a code.
No. There is no AI in this product and none is planned for anything on this page. Calling dibs is a person tapping a time; all the software does is make sure two of them cannot tap the same one. Nothing learns from who grabs what, and no outside service is asked to judge anything.
Honestly, not yet as a sheet with your name across the top. What is real is the machinery beneath — the one-per-slot rule, the tally held under a pin, the wall around a child, the blank-label feed — up and running inside the shared core these sibling products lean on, not something bolted together for this page. What is not real yet is anything wearing the dibs name: the public sheet, the free front door, the branding, the calendar tie-in. To get in early, the button here opens an email — that is the whole mechanism, and we would want to hear what you are running a sheet for before a line is built for you.