Bschedule
Two mobile apps, one scheduling system: a staff app and a customer booking app sharing the same calendars, rules, payments, and reminders underneath.
Client
Bschedule
Scope
Staff app · customer app · shared scheduling & payments
Stack
Two mobile apps · one server · one database
Separate apps for staff and customers on one backend for calendars, bookings, and notifications. Local storage only where spotty service makes it worth it.
Problem → delivery
Staff and customers needed different interfaces for the same underlying booking system. Keeping scheduling rules, payment logic, and reminder triggers consistent across both apps without duplicating business logic.
All scheduling logic, payment rules, and notification triggers live on the server. Both apps are thin clients -- they display and capture, never own the rules, so a policy change is one update not two.
Laravel backend holds booking rules, calendar state, and payment triggers. Both React Native apps talk to the same API endpoints. SQLite on-device only for offline resilience, not for business logic.
Built for real-world use
When two apps share a booking system, every rule lives in one place or it lives in two places and eventually diverges. The server owns all scheduling logic; the apps just present it.
Technologies
Tools grouped by role so you can scan without drowning in abbreviations.
Mobile apps
Backend
On-device storage
Got a project in mind?
Tell us what you need to ship. If it’s a fit, we’ll talk scope and timeline.
Get Free Consultation