Dibs.software · Call dibs on a time · 2026
You know the sign-up sheet on the fridge, or the one that goes around at back-to-school night: everybody wants the good slot, two people write their name in the same box, and somebody finds out too late. Dibs.software is that sheet with the awkward parts fixed. Post the open times, let people call dibs, and the first one there actually gets it — guaranteed at the database, not on the honour system.
And it holds one thing back on purpose: you get the open times and how many remain, never a roll-call of who else grabbed a slot. Underneath sits the booking core these sibling products all share, carried over here for the person filling in a sheet rather than someone running a booking business. It is early days — the core is running, the dibs sheet is still coming together — so this is a save-me-a-spot page, not a checkout.
How it works — three steps, and there is no step four
The whole thing is a sheet of times and a rule that only one person can take each one. Steps one and two are the dibs.software surface being built; step three is the engine underneath, which already exists.
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.
What’s built — and what is honestly still on the way
One tag per item, and each tag means something tight. Built is the boldest word here, and even it only says the machinery is up in the shared core — not that a single person has ever called dibs through this brand, because none has. Partial says the machinery is there and the dibs-branded half in front of it is not. Planned says it is drawn up and none of it stands yet. Exactly one item below is Built.
First come, first served — and it holds
By the classroom door, two hands can land on the same line of a paper sheet and nobody catches it until pick-up. A dibs sheet settles it the moment you tap: the booking core that the rest of these sibling products sit on grabs hold of that one slot and waves off every later tap aimed at it. Race a friend for the last opening at the very same second and you each hear back straight away — one of you is holding it, the other is told, then and there, that it just went — rather than a clash you both find at the door. That core is up and running now; the friendly dibs sheet you would actually tap is still in development.
Core mechanism running · the dibs sheet is still being built
Two people can never land on one slot
Keeping a slot from going to two people is not a polite check the app remembers to run — it is a rule the storage layer itself keeps. A uniqueness rule covers each live claim on a given time, and hand a slot back and that rule lets go of it again. When two taps arrive at once, only one can be recorded; the other bounces off with a tidy, retry-friendly answer instead of quietly overwriting anyone. Wording an app check carefully can still lose a tight race; this rule cannot, and every booking path across these sibling products leans on the same one, so it is worn smooth well past this single brand.
Living in the shared core · no dibs sheet points at it yet
A sheet where the other names stay hidden
The Dibs view is designed around open times and remaining capacity rather than a browsable participant list. The school-related family wall remains a design boundary for this unavailable surface. The reviewed shared core requires caller-supplied access to pass before a booking decision; that does not prove a Dibs signed-token, roster-stripping, or feed implementation. The Dibs view is in development and is not taking claims here.
Designed · no Dibs claim surface
“2 left” that is actually true
A slot with room for a few shows how many are really open — “2 left,” “last one,” “full” — and that number is re-checked, held steady, at the exact moment your tap is recorded, so it cannot quietly drift between your reading it and your tapping. One too many is turned away before a single row is saved, not apologised for after the fact. Hand a slot back and it drops straight onto the sheet for whoever looks next. The tallying is done in the core; the moving, live dibs sheet that shows it is still in development.
Tally in the core · the live dibs sheet is still being built
One simple tier
What we are aiming at is one straightforward paid tier that puts up a sheet, lets people call dibs, and carries your own name and colours across it — not a taster that yanks the useful bit away the week you come to depend on it. This is the plan talking, and it stays fuzzy on figures for a plain reason: there is nothing firm to quote. Nothing dibs-branded is on sale, and no number is set. Planned, not live.
Planned · no figure set, nothing shipped yet
It should land on the calendar you already keep
A slot you called is only worth much once it turns up in the calendar you actually open. Until that plumbing arrives — a feed you can subscribe to with names left off, and a two-way tie-in with the calendars people already live in — a called slot would sit unaware of whatever is already on your own Thursday. That plumbing is being worked on right across these sibling products and is still in active development. We would sooner point at the gap than dress a feature list up as though it were closed.
Being worked on · not finished
vs a paper sheet, and vs the tools that tried to replace it
A sign-up sheet is a lovely, human thing right up until two people claim the same slot, or everyone can read the whole list of who signed up, or the free version starts showing ads to the parents using it. The categories below each fix some of that and leave the rest.
| Product type | One-slot-one-winner, guaranteed | Other people's names hidden | One flat tier, no per-seat | Count is always current | No ads on the sheet |
|---|---|---|---|---|---|
| A paper or spreadsheet sheet | Two can claim one | Everyone's name is visible | Free, but manual | Goes stale | No |
| Open sign-up-sheet tools | Usually app-level | Browsable list | Free with ads | Sometimes | Often ad-supported |
| Appointment-link tools | Yes | One-to-one only | Per-seat | Yes | None |
| Group-poll tools | Poll, not a claim | Names visible | Free with ads | No real slot | Often ad-supported |
| Dibs.software (planned) | Yes — at the database | Designed — no name list | Planned — one flat tier | Planned — live count | Designed — no ads |
These are shapes of product, not particular companies — any given vendor’s features change faster than a page like this does, so we name none of them. Our own row says “Planned” wherever it describes the dibs product, which does not ship yet, and “yes” only where the guarantee already lives in the shared engine underneath.
Different lanes for different needs
These are separate products for separate jobs, each its own brand — not tiers of one app. They share a booking engine (no-double-book at the database, capacity under a lock, an honest waitlist), and nothing else. Naming them here is not a claim that any is live in production — each is its own brand with its own status, stated on its own page.
One link, one slot
The plainest single-link booking front door for a solo practitioner or a very small team.
Call dibs on a time
A first-come, claim-a-slot sign-up sheet with a consumer voice -- the first to grab a time gets it.
You are here
Pencil it in
Fixed-slot booking with a real soft-hold state: hold it provisionally, confirm with one tap.
More than one calendar
Appointment booking for a business with multiple staff, locations, or shared resources.
Classes & studios
Recurring class, pack, and waitlist scheduling for studios.
Cohort courses
Session-based scheduling for cohort-run online courses.
Staff shift roster
Post an open shift and match it to eligible, credentialed staff -- scheduling only.
Shifts + hours record
Shift scheduling with time-clock and hours-record capture for classified staff and shift-work teams.
Find a time
A native, ad-free poll for finding the time that works for a whole group.
The master timetable
Building the institution's whole schedule -- courses, sections, rooms, terms.
Pricing — the planned shape, and we have not set the numbers. Not a live checkout.
Here is the honest version of a pricing section for a product that does not ship yet: there is no price, because there is nothing to buy. What we can tell you is the SHAPE we are building toward — one simple paid tier that lets you post a sheet, call dibs, and put your own name and colours on it. When we set the number, the people who reserved early access hear first. Nothing on this page can take money.
Planned · one simple tier
A small paid tier — planned
No number committed · pre-launch
To be explicit, because a pricing section implies otherwise: no money changes hands through this site. dibs.software has no shipped product, no committed price, and no payment processor wired to anything — this is not a live checkout, and no card is charged. A billing seam sits in the shared codebase, switched off.
The unglamorous part we refused to hand-wave
It is tempting, for something this playful, to wave at the hard part: it is just a sheet, surely a quick check before saving the claim is enough. It is not. Two people can tap the last slot in the same instant, both read it as open, both save — and the one who lost the race does not find out until they show up. A friendly interface is a promise about how it feels, not permission to be sloppy about who really got the slot.
So none of the real rules live up in the tap-handling code. They are held by storage and by the server, down in the booking core dibs rests on, which means no later tweak can quietly drop one. That core is up and exercised today. The thing not yet standing is the dibs sheet in front of it — so what comes next is a list of what the core will not allow, not a sheet you could hand round the staffroom this afternoon.
Why it’s correct — the things the core underneath simply will not allow
The one-winner rule is a partial-unique index kept down in storage, so it is the data layer itself that turns the second grab away — never an app-level check that a tight race could slip past. Whoever comes second is handed a tidy 409 stamped ‘already_booked’, which reads as try-again, not tough-luck.
When a slot has room for a handful, the count of what is live is read with the row pinned in the very step that records your grab, so it holds steady from the instant you look to the instant you tap. One over the limit is bounced with a clean 409 ‘slot_full’ before a thing is saved.
For slots that are time windows, the ends are checked with a half-open rule on the server: a claim ending at 3:15 and one starting at 3:15 sit fine together, while one that spills a second over is refused. Because that maths is settled server-side, a browser fibbing about its own numbers gets exactly nowhere.
Dibs is designed to keep the consumer view narrow. The shared core accepts opaque references and a caller-supplied access predicate; it does not itself project a Dibs roster or publish a feed. No Dibs sheet is available here, and the broader family-wall design is not a deployed guarantee.
The existing school-related design
No Dibs school sheet is offered here. The design is intended to keep minor scheduling data consent-aware, access-controlled, and non-public. This page does not create a procedure for submitting that data.
Scoped shared evidence. The separate conference-booking route checks a recorded guardian relationship before recording a booking. The pure scheduling core also refuses a decision when its caller-supplied access predicate does not return true. Neither fact proves a Dibs signed-token workflow or a uniform missing-page response.
Unproven Dibs surfaces. A roster-stripping consent chokepoint and a names-free subscription feed are designed boundaries here. The reviewed source does not establish that Dibs reaches those mechanisms. No live Dibs roster, school sheet, or feed is supplied through this page.
What is built, what is not — plainly, because dibs is early
Standing today, down in the shared booking core: the one-per-slot rule, the live tally held under a pin and the overlap check. The broader family-wall, consent-gate, and feed claims are design boundaries for Dibs. No dibs deployment is taking claims here — shared source exists; this brand’s sheet on top of it does not.
In active development or planned: the public claim sheet, the front door, the your-own-name branding, and calendar sync. Not committed at all: any price — dibs.software has no shipped product, so there is no number to quote and we do not invent one.
Off: money and AI. Any fee would be a computed, reserved line, never charged; the payment seam exists and Stripe is not enabled, and there is no live checkout on this site. No AI decides who gets a slot, and none is claimed here. dibs.software does not hold FERPA, COPPA, SOC2, or VPAT certification.
Discuss early access
We built it in this order on purpose: the costly-to-botch bits — one winner per slot, and nobody laying eyes on anyone else’s name — came first, while the easy-to-shift bits — the sheet, the front door, the branding — are what we are shaping now. That is precisely the moment your input steers something. Nothing here rings up a sale and no card is touched: an email, a chat, and a straight answer on when your own use of it is likely ready.
To reserve early access, join the waitlist, or book a conversation: [email protected]
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.