Dibs.software
The pleasure of calling dibs, without pretending a product is available.
Dibs.software is a product proposition built around a familiar phrase: calling dibs on a time. Its public site explains a consumer sign-up-sheet idea grounded in shared scheduling work. It does not offer a deployed Dibs sheet or self-serve account. The examples on this page are fictional adult planning conversations, offered to make the distinction useful rather than merely formal.
01 · Dibs.software
Begin with the person looking at the sheet
Many scheduling descriptions start with the organiser’s dashboard. Dibs starts with a different moment: someone sees a short list of times and wants one of them. The phrase “call dibs” captures that small act without asking the person to think like an administrator. The idea suits ordinary occasions where the scarce thing is easy to describe: a short demonstration, a turn at shared equipment, or a brief conversation.
In an invented adult neighbourhood workshop, Bea wants a turn at a demonstration table. She does not want to learn a project-management system to understand three possible times. The useful design question is what she needs before making a choice: the purpose, duration, place, relevant limit, and meaning of acceptance. The result of this example is a product question, not a customer story or an adoption claim. An organiser should pause if the simple wording conceals a more complicated arrangement. If the objection is that this sounds almost too small to deserve software, small interactions can still create real confusion. The scale of the interface does not determine the importance of an accurate result.
02 · Dibs.software
The metaphor should not make the rules mysterious
“Dibs” is playful, but playfulness cannot decide who gets a contested period. A cheerful label still needs a clear distinction between seeing an opening, requesting it, and receiving an accepted result. The shared scheduling code supplies defined computations about access, time windows, and capacity. The Dibs customer experience described around that work is unavailable on this site.
Bea and organiser Oren try two versions of a fictional notice. The first says “grab your favourite time.” The second adds “one demonstration per period; use our current manual arrangement to request a place.” The second is less vague because it identifies the actual process being discussed. It does not pretend that their paper notice has become a Dibs page. Their output is a clearer description of the present arrangement. The pause is to decide what a real confirmation would mean before promising a turn to anyone. If someone objects that careful language makes a playful brand stiff, the point is to put accuracy beneath the friendly words. Familiar language works best when the person reading it does not have to guess where the commitment begins.
03 · Dibs.software
A narrow product has meaningful exclusions
A consumer sheet is not automatically a staffing rota, a client relationship system, an academic timetable, or a venue management service. Those products may share scheduling ideas while dealing with different kinds of work. Dibs has a distinct emphasis on a simple first-come choice. Links to related products explain separate scopes; they do not imply an account shared across brands or an integration available to a visitor.
Oren compares the fictional workshop need with a more complicated adult training programme. The workshop has a few independent demonstration periods. The programme has recurring groups, prerequisites, and several organisers. His comparison notes that the second problem needs questions the first example does not answer. The output is a reason to investigate fit, not a verdict that Dibs can or cannot support an unreviewed production case. He pauses before treating the family name as a feature bundle. The objection that shared code should make every sibling interchangeable overlooks the user-facing workflow. Reusing a decision function does not create the screens, permissions, records, or operational responsibility a different product would require.
04 · Dibs.software
Source evidence deserves a small, accurate sentence
The shared core takes caller-supplied values and returns decisions. Its access predicate must return true; otherwise the decision refuses access. Its fixed-slot calculation checks supplied bookings against capacity. Its time-window calculation evaluates the stated intervals. These are specific pieces of source evidence. They do not establish that a Dibs route stores a booking, that a public sheet refreshes, or that a notification reaches anyone.
Bea writes a comparison sentence for the fictional planning meeting: “The product idea has shared scheduling computations behind it, but this site does not give us a working sheet.” That is both positive and bounded. It identifies something real without turning a source file into deployment proof. The result helps Oren decide whether a conversation is worth having. The pause is to remove adjectives that add an unverified guarantee, such as seamless, automatic, or fully integrated. If a colleague asks why the explanation is so careful about source, a product decision depends on what can actually be used. A computation, a reachable route in another workflow, and a delivered customer surface answer different questions.
05 · Dibs.software
An enquiry can be specific without becoming an application
A useful message might say that an organiser has one adult workshop resource, three short periods, and a manual process that becomes confusing when people change their minds. That gives a human reader enough context to understand the problem. It does not need a real attendee list, a copied record, or a claim that an account is being opened. The contact action remains an email link.
Oren’s fictional draft reads: “We are considering a clearer first-come arrangement for a small adult demonstration. We would like to discuss how you describe acceptance and changes. We understand this public site does not provide a live sheet.” The output is a focused question. It is not a reservation for early access, a purchase order, a support entitlement, or confirmation that anyone has read the message. The pause is to check whether those are actually the questions the organisers need answered. The objection that a short enquiry might be too vague is answered by the concrete shape of the example. Specificity comes from the scheduling problem, not from sending more personal information or inventing a transaction.
06 · Dibs.software
Keep enthusiasm proportionate to the offered action
A product can have a clear point of view before its customer surface is available. Dibs describes the appeal of a first-come sheet, the shared work supporting parts of the idea, and the places where the public site stops. There is no live checkout, no committed price to accept here, and no AI deciding who gets a time. A conversation about the idea does not activate any of those things.
At the end of their fictional meeting, Bea and Oren keep their existing manual arrangement and note one open product question. That is a legitimate outcome of reading an about page. It neither endorses the product as ready nor dismisses the underlying idea. Their pause is to ensure that anyone receiving the notes can distinguish the illustrative example from an actual service offer. If the final objection is “What can I do here, then?”, the answer is concrete: read the explanation, compare the scope, and use the contact information for an enquiry if it fits. None of those actions creates a booking, publishes an event, sends a reminder through Dibs, or transfers responsibility for an organiser’s real arrangements.
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.