Dokti — Booking & Reservations Platform

The build

A salon's real inventory is a Tuesday 2 o'clock — if it sits empty, it evaporates. Dokti exists for businesses whose product is time: availability is modelled honestly per staff member with buffers and service durations that actually sum, reminders arrive as text a human would send (“reply C to confirm”), no-shows cost a bKash deposit that refunds on time arrival, and the walk-in who hates apps still gets a scannable token and truthful minutes. Booking platforms sold here are calendars bolted onto a website theme; Dokti is an operations engine wearing a polite face — and we prove the responsiveness on two devices with the same pixels and the same numbers, because a booking app that disagrees between laptop and phone is two broken apps.

What we handled

• Per-staff availability with buffers, overlap rules and “hold for walk-in” capacity — the week grid is the business's real heartbeat
• Service durations that sum into real slots: a 120-minute bridal never double-books into a 45-minute cut's gap
• Reply-C reminder loops: confirm counts, reschedule absorbs and no-show histories live on the booking card
• Deposits per category via bKash/Nagad — refundable on time arrival, applied on late cancel, waived for regulars by rule
• Walk-in tokens with scannable QR and honest chair timers — queue status the customer can watch from the tea stall
• One design system, two surfaces: Next.js web and a Flutter companion app rendering identical states — verified, not promised

An empty Tuesday 2 o'clock cannot be restocked

A salon that loses a two-hour bridal slot to a no-show has not lost ৳8,500 — it has lost ৳8,500 that no later walk-in can backfill, because the chair was reserved against a calendar that nobody trusts. Every time-based business in the country runs on the same three fragile habits: an Instagram DM as the booking system, a phone call as the reminder, and the owner's guilt as the cancellation policy. Booking software sold locally is a Google Calendar embed with a logo; the ones sold globally bill in dollars and pretend walk-ins do not exist.

Dokti was scoped from those exact failures: model availability the way a staff member actually experiences it (buffers between chairs, a senior who takes longer, a Tuesday the owner blocks for training), make durations arithmetic that sums, give confirmations a reply mechanism instead of a read-receipt, and price the no-show with a deposit the customer pays happily when it is refunded on time.

The calendar is the product

Availability is generated, not typed: per-staff schedules, service durations, setup time and buffer rules compile into the free slots a customer may book — including the clever ones, like “hold this gap for walk-ins until 11:00” or “a 120-minute service needs a 150-minute runway.” The week grid on the owner's laptop and the day rail on the customer's phone render from the same compiled truth, which is why “it looked free when I booked” cannot happen. Overlaps are impossible by construction, and a booking that would starve the queue warns before it commits.

Multi-chair shops get capacity as a number with rules attached: four stylists, two chairs in color, a dryer that one person shares — the engine refuses bookings the room can physically do but the equipment cannot. This is boring work, and boring work is why our salon pilots keep their calendars without a spreadsheet appendix.

Confirmations that ask, and deposits that answer

The reminder loop is the no-show weapon and it is written like a person: “See you tomorrow 10 AM with Blush & Blade — reply C to confirm, R to reschedule.” Confirm counts tick on the business-home card in real time, non-repliers escalate to a call queue, and reschedules re-solve the calendar instead of leaving a hole. The language is a template the owner can edit, but the reply protocol is the product — an appointment with an unconfirmed attendee is a rumor.

For the slots that genuinely hurt — bridal, Saturday prime, the 6-top table — a deposit per category, payable via bKash or Nagad, converts the rumor into a contract: refunded the moment the customer checks in on time, applied on a late cancel per policy, auto-waived for regulars whose history earned trust. The deposit rule is the owner's dial, not ours; the software's job is to make honouring it automatic and auditable, refund trails included.

The walk-in is a citizen, not an error case

Foreign booking software treats walk-ins as noise; half this country refuses to book anything days ahead. Dokti hands the front desk a token board — issue Q-16 with one tap, the guest's phone glows with a QR and honest minutes, and the chair timer counts down from what the queue actually implies, not what the receptionist wishes. “First in line for Chair 2” is computed from committed bookings and their summed durations; when the math says it would lie, the board says “+15 min from schedule drift” and owns it.

The guest can leave the queue from the tea stall and keep their place for re-entry by rule, the desk can bump a no-show's reservation into the queue head, and every queue state renders on both screens because a queue the customer cannot see is a queue that gets argued with.

One design system, proven on two devices

The renders on this page are MacBook and iPhone side by side for a reason: they show the same components, same numbers and same states on both surfaces — web built in Next.js, mobile as a Flutter companion, both generated from one token set and one state machine. Responsive, in our sense, is not a layout trick; it is an agreement between devices about what is true. Where the surfaces intentionally differ — the kanban living on the desk, the ticket living on the phone — the caption says so rather than hiding it in a mockup.

This is also how we work for the rest of the portfolio, and it is the standard we ask owners to hold any vendor to, including us: open the same booking on laptop and phone, in daylight and at 2 a.m., and ask which one is lying.