BSchedule

The Problem

A business client needed scheduling for two audiences — staff managing availability and jobs, and customers booking appointments — without two backends that would drift apart.

What I Built

BSchedule is two React Native apps (staff/admin and customer) against one Laravel REST API / MySQL:

• Appointments create/edit/search; calendar and timeline (notes, reminders).
• Staff and customer management; job cards; notice board.
• Garage-style service categories (Service, Repair, MOT, Tyres, Diagnostic).
• Google Sign-in; admin demo mode for UI without a live backend.

Product host: bscheduled.co.uk.

Major Features

• Dual portals — staff depth vs customer booking surface on the same schedule.
• Calendar + jobs — day views, job cards, notices, vehicle reminders.
• Single API — availability and bookings live in one place.
• Auth — Google Sign-in for real accounts; demo path for review builds.

Key Challenges

One REST API had to serve different permissions and shapes of the same schedule: staff needed broad read/write; customers needed a narrow booking surface. Endpoint design up front mattered more than shipping two “almost the same” APIs.

Results

BSchedule shipped as a production booking system — staff and customer apps on one shared API — so scheduling data couldn’t fork.

Stack Decisions

A single Laravel API was chosen specifically to avoid the classic failure mode of staff/customer systems: two stacks, two truths. React Native + Redux kept both clients shippable on the same design language without a web-only compromise.