Features · Slotly.software
The hard guarantees are built; the useful product around them is still being assembled.
Feature status follows the whole path. A database invariant is built. A public link, operator screen, integration, or paid tier remains planned until someone can use and support it.
Built decision features
Uniqueness, capacity, and overlap checks live below the future interface.
The fixed-slot core prevents a second live booking for the same resource and window with a partial-unique database index. It checks a multi-place slot’s live count while holding the relevant lock. It also evaluates whether the requested interval overlaps another live interval for the resource. These are separate guarantees because a duplicate exact window, a full multi-capacity slot, and a partial overlap are different conflicts.
The response preserves machine-readable reasons such as already_booked and slot_full, allowing a future interface to offer the correct next step. The rules are unit-tested in the shared engine. They do not establish a public Slotly endpoint or product deployment.
Planned product features
The link, embed, packaging, poll, and calendar connections are named by status.
A single public booking link and embed are in development. The planned entry Plus tier carries no monthly booking cap and includes a custom domain. Both tiers’ packaging remains display-only; white-label is planned at Team, not held for an Enterprise contract. No tier can be purchased from this site, and no feature is made live by appearing in a price card.
A native group poll is planned for the question of which time works across several people. Two-way Google and Microsoft calendar connections and a CalDAV server are also planned. Each needs a complete user authorization and conflict lifecycle. None is connected here, so the page does not ask for a calendar permission or imply that outside events already subtract from availability.
Supporting features still need work too: accessible configuration, time-zone previews, exception dates, cancellation policy, retry-safe notifications, operator history, support tooling, data export, and account deletion. The intended product stays plain by making those responsibilities visible rather than replacing them with an AI scheduling claim.
An original adult planning example
Give each collision its own example.
A fictional equipment-demonstration desk uses three paper cases to evaluate the feature list. In the first, two requests name the same resource and the same 13:00–13:20 interval. In the second, one request names 13:00–13:20 and another names 13:10–13:30 for that resource. In the third, a group session has four places and the planning sheet already marks four as occupied. These examples are invented inputs, not actual bookings.
The first question concerns a repeated exact window. The second concerns a partial overlap even though the two requests have different start times. The third concerns a quantity limit. Calling all three “double booking” can make a feature discussion imprecise. The existing core description distinguishes uniqueness, overlap and capacity, so the evaluation should preserve those separate questions.
For the capacity case, the paper arithmetic is simple: four marked places out of four leave none. If only three were marked, one would remain in that snapshot. That does not prove a real request can still claim it, because the authoritative decision may occur after the snapshot. The example teaches what the quantity means without pretending to execute a concurrency test.
The objection is that an end user does not need three technical labels. The interface can use plain language, but the evaluator still needs to know which outcome is being demonstrated. A feature should not receive credit for rejecting an exact duplicate if the requirement actually concerns partial overlap. One successful case cannot stand in for the other two.
An original adult planning example
Write the expected result before accepting the demonstration.
In a second fictional review, adult operator Avery writes a feature card with four lines: the starting arrangement, the attempted request, the expected result and the evidence required. For an already occupied one-person window, the result is a refusal, not a second confirmation. Evidence would have to show the request outcome and the absence of an additional live claim. This site supplies an explanation of that boundary, not the running demonstration.
The first version of Avery's note says, “The page displays an error, so collision handling passes.” That is too broad. An unrelated error could also prevent completion. The revised note asks for the conflict that belongs to the chosen case. The named already_booked and slot_full responses described here are useful because they identify a particular reason rather than an unexplained failure.
A successful-looking screen deserves the same scrutiny. A selected time, a disabled button or a celebratory heading does not independently establish a committed booking. The feature card should say which result makes the commitment real. If the evaluation cannot obtain that evidence from a Slotly surface, keep the surface's status unavailable instead of passing the feature on visual appearance.
This method makes a refusal useful rather than embarrassing. For a full session, declining another request is the expected outcome. For an open candidate, declining because of an unrelated missing service proves something different. The evaluator should record what happened without moving the success criterion afterward to match whichever screen appeared.
An original adult planning example
Keep an essential dependency separate from an attractive feature.
Suppose Avery's real requirement, stated here only as a fictional scenario, is to avoid offering times that conflict with an external calendar. A plain booking link would be useful, but it would not by itself satisfy that dependency. This page labels external-calendar connections as planned. An evaluation cannot turn that missing connection into an existing capability by showing a carefully prepared sample week.
The same distinction applies to branding. A mockup with a studio name demonstrates a visual choice. It does not establish a working custom-domain connection, a supported white-label configuration or an account that can save either setting. Planned packaging describes the product account already given above; it is not a set of controls on this page.
A useful feature summary therefore has more than a yes column. It records the described engine rule, the unavailable surface and the human or external dependency the proposed workflow still needs. For Avery, calendar conflict subtraction stays an unmet requirement even if the exact-window explanation is convincing. That is a concrete reason to stop short of treating the workflow as ready.
The reasonable question is whether this makes the list less useful for choosing. It makes the choice more specific. Someone who needs only to understand the core decision can learn from the built-rule explanation. Someone who needs a working external connection gets a clear current refusal. Neither reader needs an invented activation date or a promise that an inquiry makes the dependency available.