Skip to content

An independent concept project by 4sidedevelop. Screens and data are illustrative.

Concept project

Mobile App & Booking Platform

Slotly

Booking app for appointment-based services

A mobile booking concept: choose a service, a specialist, and a free time, then reschedule from the app. Administrators get a team schedule that prevents overlapping bookings.

Category
Mobile App & Booking Platform
Proposed stack
React Native, TypeScript, Node.js API, PostgreSQL, Push notifications
Status
Concept — not a client project
Booking in three screens. Choose a service, pick a free time, and confirm. Each screen does one job.

01

The challenge

A client wants to find a time that suits them and book the right specialist without calling. Today that often means a phone call during working hours, or a message thread that goes back and forth about availability.

The administrator manages the team’s schedule by hand. Overlapping appointments, late changes, and forgotten reminders make the day hard to plan.

02

Who it’s for

  • Client

    Books, reschedules, or cancels from a phone and gets a reminder before the visit.

  • Specialist

    Sees their own day, breaks, and the details of each appointment.

  • Administrator

    Manages the team’s schedule, working hours, and exceptions from a desktop.

03

The proposed solution

The concept keeps booking to three screens — service, time, confirmation — and puts everything else one step away. Availability is calculated from working hours, service length, and existing bookings, so the app only offers times that can actually be booked.

  • Service and specialist

    Duration and price are visible before choosing.

  • Availability calendar

    Only free slots long enough for the service are shown.

  • Confirmation

    A clear summary with a calendar invite.

  • Reschedule and cancel

    From the app, with the policy shown first.

  • Reminders and history

    A reminder before each visit and a list of past visits.

  • Admin schedule

    The whole team in one day view, with conflicts blocked.

04

Key workflows

  1. 1Book an appointment

    1. Step 1: Choose a service and see its length and price.
    2. Step 2: Pick a specialist, or let the app choose any available one.
    3. Step 3: Choose a free time and confirm the booking.
  2. 2Reschedule from the app

    1. Step 1: Open the upcoming visit and choose Reschedule.
    2. Step 2: Pick a new free time; the current booking stays in place until the change is confirmed.
    3. Step 3: After confirming, the old time is released for other clients.
  3. 3Cancel within the policy

    1. Step 1: Choose Cancel; the cancellation policy is shown before the final button.
    2. Step 2: The slot is released and the administrator is notified.
  4. 4Manage the team schedule

    1. Step 1: The administrator sees every specialist in one day view.
    2. Step 2: A booking can be moved to another free slot.
    3. Step 3: A move that would overlap is blocked, with the next free time suggested.

05

Screens

Illustrative screens with sample data, designed for this concept.

Reschedule and cancelThe upcoming visit, a new time chosen next to the current one, and a cancellation sheet that states the policy first.
Reminders and visit historyA reminder the day before, past visits with Book again, and notification settings the client controls.
Administrator scheduleSpecialists as columns across the day. Moving a booking onto an occupied time is blocked and explained.

06

Design decisions

Only bookable times are shown

A slot appears only if the full service length fits before the next booking or break, so clients never pick a time that has to be corrected later.

Start and end on every slot

The selected time shows its end, for example 10:30–11:15, so a long service is not mistaken for a short one.

Policy before the button

Rescheduling and cancellation rules appear before the final action, not in a message afterwards.

Conflicts explained, not just refused

In the admin schedule, an overlapping move names the booking it collides with and suggests the next free time.

07

What to validate

The concept is a starting point. These questions would be tested with users and resolved during implementation.

  • Whether clients prefer choosing a specialist first or a time first.
  • How far ahead people book, and how many days the calendar should show by default.
  • Reminder timing and channel: push notification, SMS, or email.
  • Cancellation policy wording that is clear without feeling punitive.
  • Time-zone handling for online sessions and clients who travel.

Proposed stack: React Native, TypeScript, Node.js API, PostgreSQL, Push notifications. The screens on this page were built with React and Tailwind CSS for this demonstration.

Have a similar project?

Tell us about the workflow you want to change. We reply with a clear next step, not a pitch deck.