Dibs.software
Calling dibs starts with a clear offer, not a quick finger.
This is a worked explanation, not an interactive booking screen. Dibs.software has no shipped claim surface. The shared scheduling code contains real decision functions; the fictional workshop below shows the human questions those functions cannot answer for an organiser. No example places a reservation, updates a calendar, charges a card, or sends a reminder.
01 · Dibs.software
Start with something a person can actually choose
Mara runs a fictional repair evening for adult volunteers. She has one bench, three twenty-minute demonstration periods, and a printed invitation that currently says “drop by after six.” Ellis, another organiser, points out the problem: that sentence offers an evening, while the actual scarce thing is a period at one bench. They write down 18:00–18:20, 18:20–18:40, and 18:40–19:00, all on the same invented date and at the same place. These are illustrative times, not available appointments.
Their revised description is: “Choose one twenty-minute bench demonstration. Each period has room for one participant. Arrive at the entrance before your chosen period begins.” The result is clearer wording for their own manual arrangement. It does not establish who may attend, whether the equipment is ready, or whether the organiser has authority to offer that room. Mara pauses until those ordinary practical facts are checked. The objection that a friendly invitation should stay short is reasonable; precision belongs in a few useful sentences, not an intimidating form. A time without its purpose is still an incomplete offer.
02 · Dibs.software
Separate a displayed choice from an accepted claim
Ellis copies the three periods onto a paper planning sheet. At that moment all three are unassigned. That observation is not a guarantee that a later request succeeds. Another person can ask for the same period between reading a list and making a request. The distinction matters even if everyone acts honestly. A stale sheet is a problem of timing, not proof that someone cheated.
The shared fixed-slot decision accepts a slot key, a capacity, existing bookings, and an access predicate, with optional checks supplied by its caller. It counts matching booking keys against the capacity. The pure function returns a decision; it does not write a booking or refresh a public screen. In the specimen, Mara records: “18:20 is shown as unassigned on our working copy; confirmation is a separate step.” That is a manual status note. The result makes the remaining question visible. If someone objects that this sounds less convenient than a big green button, the answer is that a convenient label cannot replace an accepted result. Dibs does not provide that button or its acceptance workflow here.
03 · Dibs.software
Make the refusal meaningful without inventing a promise
Suppose the fictional capacity for the middle period is one and the supplied list already contains one booking for its key. The fixed-slot decision refuses an additional booking. If the access predicate is missing or does not return true, it refuses access before doing that capacity work. Those are actual branches in the shared function. They are not a statement that the Dibs brand has a deployed booking service or that every caller supplies a correct list.
Mara’s manual response is: “I cannot confirm the middle period from this sheet because it is already allocated. The earlier and later periods need checking separately.” The output is an explanation of one refusal, not a reassignment to a different time. Ellis does not silently put the requester into the later period. A refusal can be useful without becoming an automatic alternative offer. The human pause is to verify what remains open and let the person make a new choice. The objection that a swap would save correspondence overlooks the changed commitment: a different time is a different choice, even when it looks equally convenient to the organiser.
04 · Dibs.software
Treat adjoining times as an explicit rule
The shared time-window decision uses half-open intervals. Under that rule, one period can end at the exact instant the next begins without the two intervals overlapping. A period that extends beyond the boundary is a different case. The computation takes the caller’s start, end, existing holds, access rule, and capacity inputs. It does not inspect the workshop floor or decide whether a participant needs time to put tools away.
Ellis therefore keeps two questions separate in the specimen: “Do these written intervals overlap?” and “Can the bench actually be ready for the next demonstration?” The first can be answered from the supplied numbers. The second needs a practical judgement about the activity. If Mara needs five minutes between demonstrations, she must express that in the arrangement rather than assuming the interval calculation invents a buffer. Their output is a revised planning note with the preparation gap written down. The objection that precise arithmetic should solve the whole scheduling problem confuses correctness about numbers with completeness about an event. Neither this explanation nor the shared decision moves equipment, checks a clock on site, or manages arrivals.
05 · Dibs.software
Record what changed when a person changes their mind
In the fictional exercise, a participant no longer wants the earliest period. Mara writes a cancellation note beside the original allocation and checks which working copy Ellis is using. She does not describe the period as available merely because someone mentioned a possible cancellation. There is a difference between hearing a request, accepting the change under the organiser’s arrangement, and revising the sheet people consult.
The shared pure scheduling decision has no knowledge of this conversation. It evaluates the booking or hold inputs supplied on a particular call. Removing a record from a hypothetical list can change a subsequent computed result, but that is not evidence of a Dibs cancellation endpoint, a stored cancellation, or a live refresh. The specimen result is deliberately modest: “Our working copy records the cancellation; check the current allocation before offering the period again.” The pause belongs to the people maintaining that arrangement. If an organiser asks whether the person can cancel in one tap, this site does not supply that action. Explaining the desirable experience does not make the account, confirmation, or cancellation workflow available.
06 · Dibs.software
Finish with an honest description of what this site does
A useful enquiry about Dibs can describe this adult example without sending a real participant list: one resource, three periods, one place per period, and uncertainty about how changes should be communicated. The contact link opens an email composer. It does not reserve a place in a product, create an account, allocate a workshop period, or confirm a response time. A message remains a request for a conversation.
This page uses the shared decision functions as evidence for specific computations and refusal branches. It does not turn their presence in source into deployment proof. Money and AI remain outside the offered Dibs surface: there is no live checkout here and no AI choosing a time for anyone. The existing school-related design is described separately with its limits; this adult worksheet creates no procedure for handling a child’s information. The final objection is often practical: “Can I use the story as my booking system?” You can consider the wording as an example, but it is not an operating system of record. An organiser still needs an actual arrangement, an authorised channel, and a clear way to know what has been accepted.
Keep the next step clear
Contact Dibs.software for a human enquiry. This page does not create a sheet or accept a claim. Read the starting point and help page for the existing product status.