Krunal Patel
Case Study 02 · Internal Platform

MeetMira — Replacing a Third-Party Scheduling Platform

An enterprise scheduling platform built to replace YouCanBookMe entirely — with Round Robin and Collective booking, centralized calendar access, and transaction-safe booking that prevents double-bookings across staff calendars.

0
Double-bookings
100%
SCHEDULING SaaS RETIRED
2
ROUTING MODES
Async
SIDE-EFFECT PROCESSING
The Problem

Mirasee's internal teams relied on YouCanBookMe for staff scheduling, creating both a recurring SaaS expense and architectural limitations around how bookings could be routed across departments.

The bigger problem was onboarding. Every staff member who needed to receive bookings had to authenticate individually and manage their own calendar permissions, creating recurring IT overhead whenever someone joined a booking team.

The requirement was straightforward on paper: replace YouCanBookMe completely, support the company's Round Robin and Collective booking rules, eliminate individual calendar setup, and make double-booking impossible even when requests arrived concurrently.

The Architectural Challenge

The difficult part wasn't building a booking form. It was making the booking engine correct.

Multiple calendars, multiple routing modes, centralized authorization, concurrent requests, and unreliable external services all had to coexist without allowing two users to successfully claim the same availability.

The architecture therefore separated the critical booking transaction from everything that could safely happen afterward.

Architecture

The system was designed around one principle: booking confirmation must remain independent from everything that happens after a booking is created.

The synchronous path handles availability and booking state; email delivery, CRM synchronization, calendar updates, and redirects are processed asynchronously through background workers.

font-size="12" class="fill-slate-500 dark:fill-slate-400 font-mono" >booking transactionasync side effectsDomain-Wide DelegationClientReact 19 + ViteAPIExpress 5 + TypeScriptBooking EngineRound Robin · CollectiveATOMIC BOOKING TRANSACTIONGoogle WorkspaceCalendar read / writePostgreSQLPrisma ORMBullMQ / RedisAsync Processing BoundaryBackground WorkersResend email sequencesOntraport data syncCalendar + redirect updatesBOOKING CONFIRMATION DOES NOT WAIT FOR SIDE EFFECTSEmail · CRM sync · calendar writes · redirects

The booking interface never waits on email delivery, CRM sync, or calendar writes — all routed through the queue.

Key engineering decisions

Where the hard problems actually were

Auth

Domain-Wide Delegation Instead of Per-User OAuth

Individual OAuth consent would have created an authorization and IT workflow every time a new staff member became bookable. Domain-Wide Delegation allowed the platform to read and write to employee calendars through a centralized Mirasee-controlled authorization model.

The result

Enforced strict design consistency across five brands, reducing Project Managers' QA workload exclusively to copy edits.

Availability

The Calendar Became the Availability Configuration

Instead of introducing another availability-management interface, staff used the calendar they already worked with. A matching calendar block represented bookable time, making the existing calendar the source of truth for availability.

The result

No new scheduling interface to learn. No second availability system to maintain.

Concurrency

Atomic Booking Transactions

Round Robin and Collective routing both have to evaluate multiple calendars and then commit a booking before another request can claim the same slot.

The booking confirmation path therefore performs the availability check and commit atomically against real-time availability.

The result

Concurrent requests cannot both successfully claim the same slot.

Reliability

Asynchronous Side Effects with BullMQ + Redis

A successful booking should not depend on whether an email provider, CRM API, calendar update, or redirect operation happens to respond quickly.

Those operations are therefore pushed onto a BullMQ/Redis queue after the booking has been committed.

The result

External-service latency or failure can affect a side effect without affecting the booking itself.

MY ROLE

I designed and built the platform end to end — including the booking engine, Google Workspace calendar integration, Round Robin and Collective routing, centralized calendar authorization, transaction-safe booking logic, background processing, CRM synchronization, and production infrastructure.

PRODUCTION STACK

Frontend

React 19 & ViteTailwind CSS 4

Backend & DB

Node.jsExpress 5 & TypeScriptPostgreSQLPrisma ORM

Infra & Services

BullMQ & RedisDockerGoogle Workspace APIResend
Results

What shipped

Scheduling SaaS Retired

The recurring third-party scheduling subscription was eliminated completely, with the replacement platform covering the required booking workflows without a functionality gap for end users.

Zero Individual Calendar Setup

Domain-Wide Delegation removed the per-user authorization workflow. New staff could become bookable without completing their own OAuth setup or creating an IT ticket.

Concurrency-Safe Booking

Atomic booking logic across Round Robin and Collective routing has held up under real concurrent booking load, preventing competing requests from successfully claiming the same slot.

Replacing an Expensive SaaS Dependency?

Let's look at the architecture, economics, and migration path.

When a third-party tool becomes expensive, restrictive, or difficult to integrate with your business rules, the answer isn't always another SaaS subscription.

Any questions? AI Interview
Start AI Interview