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
Here is the bit a fridge-door sheet fumbles and dibs is careful about. Your view is the open times and an honest tally of what remains, and not one word about the people who took the other slots. Nothing to scroll, because no such list is ever handed out. Where a sheet leans on student records — a parent-teacher slot, for instance — a guardian only ever reaches their own child, the child is identified by a signed token settled on the server instead of anything the browser typed, and a poke at another family comes back looking exactly like a page that was never there — so nobody can turn the sheet into a way to read off who signed up. That wall lives in the shared core; the dibs view onto it is still in development.
Wall in the shared core · the dibs view is still being built
“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
Free to call dibs
What we are aiming at is a truly free way to put up a sheet and let people call dibs — not a taster that yanks the useful bit away the week you come to depend on it — with a modest paid step above it for anyone who wants their own name and colours across the sheet. 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 | Free front door, 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 | Yes — by construction | Planned — free front door | Planned — live count | Planned — none, ever |
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 — a genuinely free way to post a sheet and call dibs, and a small paid tier for people who want their own name and colours on it. When we set the numbers, the people who reserved early access hear first. Nothing on this page can take money.
Planned · free front door
Free — planned
No number committed · pre-launch
Planned · small paid tier
A step up — 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.
The no-names wall sits in the shared core, underneath any idea of a sheet: a guardian reaches only their own child, that child is pinned by a hash-verified server-side claim, and a poke at another family comes back as a uniform 404 rather than a hint. The dibs view onto this is planned — read it as a promise about how it gets drawn, on a wall already standing.
When a sheet involves a kid
The friendliest use of dibs — a teacher posting parent-teacher slots — is also the one that touches a child’s information, so the wall around it is not an afterthought. Three mechanisms carry it, and each runs on the server where a crafted request cannot reach it:
The family wall. A guardian gets to their own child and no further. The child is settled from a hash-verified server-side claim, never from a value the browser handed up, and any reach past that claim answers with a uniform 404 — the same blank a made-up address gets — so a nosy visitor is handed no thread to pull on who signed up.
The consent chokepoint. Read a class list and every name meets this gate first. A child marked private, lapsed, or do-not-publish has their name pulled and grade blanked, stripped at the server before the page ever comes back — genuinely gone, not parked behind a screen toggle a doctored request could flip — and the row still counts, only the identity drops away.
A feed you subscribe to carries no names. Any such feed leans on opaque labels: no student name, no teacher name, a non-PII handle standing in for a real address. Subscribe to your own and you cannot spill a run of names into whatever calendar app you keep.
All of this stands in the shared core dibs is built on. The dibs sheet that will put a face on it is still in development, and no dibs surface is holding a child’s data today, for the plain reason that no dibs surface is serving anyone yet.
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, the overlap check, the wall around a child, the consent gate, and the names-left-off feed. No dibs deployment is taking claims for anyone yet — the core runs; this brand’s sheet on top of it does not.
In active development or planned: the public claim sheet, the free 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.
Reserve 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 free 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
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.