What if you could rebuild an enterprise platform in a weekend?

We reverse-engineered a decade-old scheduling platform—31 repositories, 658,000 lines of code—and rebuilt it from scratch on modern infrastructure at near-zero marginal cost per customer.

See How ↓ Try the Apps
The Problem
A platform buried under a decade of entropy
The legacy platform spans 31 repositories built over 12+ years. Ruby 2.3.3 and Rails 4.0.13—both end-of-life for 7+ years. Four coexisting scheduling engines. Three cart implementations. Six API versions running simultaneously. Every tenant sharing MySQL shards, Redis clusters, Sidekiq queues, and Kubernetes pods that cost real money whether anyone books an appointment or not.
658,633
Lines of Ruby (monolith)
31
Repositories analyzed
258
Database tables
287
ActiveRecord models
1,412
Legacy spec files
6
Coexisting API versions
18+
Payment processors
4
Scheduling engine generations
62
Background job workers
1,500+
Database migrations
Reverse Engineering
Every line read. Every behavior captured.
We didn't just read the code—we ran it. We stood up the legacy monolith in Docker (Ruby 2.3.3, Rails 4.0.13, MySQL 8), executed 996 scheduler specs with zero failures, and built an automated fixture extraction harness that exercised the actual production engine to generate provably-correct test oracles. Every fixture traces back to real legacy behavior.
996
Legacy Specs Validated
Ruby scheduler suite, zero failures
527
Oracle Fixtures
JSON from actual legacy engine
364
TypeScript Fixtures
Across 10 fixture files (7,500 lines)
4,177
Lines of Behavioral Specs
Acceptance criteria for every module
Clean-Room Test Harness
891 total fixtures (364 TypeScript + 527 JSON oracle) form a clean-room testing harness. The TypeScript fixtures define expected behavior extracted from specification analysis. The JSON fixtures are generated by exercising the actual legacy engine inside Docker—provably correct outputs from provably correct inputs. Together, they let us validate our rebuild against the real system without copying a single line of legacy code.
Architecture
Cloudflare-native. Zero servers.
Every component runs on Cloudflare's edge. Workers for compute, D1 for storage, Durable Objects for coordination, R2 for assets, Queues for async jobs. Each customer gets isolated databases—not shared shards. The cost of an idle tenant approaches zero.
Frontend Apps — Cloudflare Pages
Admin Portal
React 19
Booking Flow
React 19
Staff Portal
React 19
Kiosk
React 19
Edge Gateway
Edge Gateway
Tenant resolution • Auth • Rate limits • CORS • Tracing
Domain Workers — Hono
Auth
JWT / Roles
Catalog
34 tests
Availability
35 tests
Booking
41 tests
Events
28 tests
Payments
20 tests
Notifications
21 tests
Integrations
20 tests
Queue
26 tests
Reporting
44 tests
Shared Packages
Schedule Engine
121 tests • 891 fixtures
API Contracts
Zod / OpenAPI
Domain Types
TypeScript
Cloudflare Infrastructure — Per Tenant
Control Plane D1
Tenant registry
Config D1
Per-tenant config
Ops D1
Per-tenant data
Durable Objects
Booking locks
R2
Assets
Queues
Async jobs
Spotlight: Reporting Engine
D1-native analytics. No data warehouse required.
The legacy platform pipes data through Elasticsearch, Looker, and custom ETL jobs to produce reports. Voyage runs analytics directly against D1 using SQL aggregations at the edge—no separate data warehouse, no ETL pipeline, no additional cost.
5
Report Types
Bookings, revenue, staff utilization, customer retention, and CSV export. Each with date range filtering, drill-down by service/staff, and trend analysis.
44
Tests
Full coverage of aggregation queries, GROUP BY, heatmaps, day-of-week analysis, lead time calculations, cancellation rates, and CSV generation.
0
External Dependencies
No Elasticsearch. No Looker. No ETL. Pure D1 SQL with strftime, julianday, GROUP BY, HAVING, and CASE expressions running at the edge.
Built-in Analytics
Booking reports: status breakdown, top services, day-of-week & hourly heatmaps, cancellation rate, average lead time, daily trend
Revenue reports: total/paid/unpaid/refunded, by service, by staff, daily trend
Utilization: per-staff booked hours vs available hours, busiest/least busy, peak hours
Customers: total, new vs returning, retention rate, top customers, avg bookings/customer
Export: CSV for bookings, orders, customers, audit events with proper quoting
Full audit trail included
Every mutation (booking, cancellation, reschedule, check-in, config change) writes to an append-only audit_events table with actor, action, entity, and timestamp. Admin and internal audit endpoints with date-range queries and CSV export. Compliance-ready from day one, not bolted on later.
The Proof
449 tests. All passing. All green.
12 domain workers, each with its own test suite. A scheduling engine backed by 891 golden fixtures extracted from the running legacy system. Four behavioral specification documents covering every module. Nothing hand-waved.
449
TypeScript Tests
Across 12 workers + schedule engine, including 101 edge case tests covering DST, concurrency, capacity, and more. All passing.
891
Golden Fixtures
364 TypeScript + 527 JSON oracles. Every fixture traces to real legacy engine behavior. Clean-room methodology.
12
Domain Workers
Auth, Catalog, Availability, Booking, Events, Payments, Notifications, Integrations, Queue, Reporting, Edge Gateway, Control Plane.
4
Frontend Apps
Admin portal, customer booking flow, staff portal, self-service kiosk. React 19 on Cloudflare Pages.
Build Phases
Phase 0
Evals
Phase 1
Control Plane
Phase 2
Bootstrap
Phase 3
Scheduling
Phase 4
Booking
Phase 5
Frontend
Phase 6
Payments
Phase 7
Staff
Phase 8
Events
Phase 9
Queue
Phase 10
Integrations
Phase 11
Harden
Try It
Four apps. Running now.
Each frontend is a React 19 application running on Cloudflare Pages. Tap any card to explore the live demo with mock data.
B
Customer Booking
5-step booking flow: location, service, staff, time, confirm. Mobile-first.
A
Admin Portal
Dashboard, bookings, services, staff, resources, scheduling, customers, settings.
S
Staff Portal
Day view, queue management, check-in, walk-in registration.
K
Self-Service Kiosk
Touch-friendly check-in, queue join, large text, accessibility-first.
The Economics
Case study: HSBC UK on Voyage
Not a hypothetical. We modeled the actual scale of one of the platform's largest enterprise customers—HSBC UK—against real Cloudflare pricing. 327 branches, 1,308 staff, 1,962 appointments per day, 510,000 bookings per year.
327
UK Branches
Each with ~4 booking-relevant staff
1,308
Staff
Needing schedules, calendars, portals
1,962
Appointments / Day
6 per branch × 260 working days/yr
510K
Bookings / Year
~42,500/month × 2KB each
Monthly Request Volume Model
Traffic Source Requests / Month Assumptions
Customer booking flows 637K 42.5K bookings × 15 API calls each
Browsing (no booking) 1.9M 3× booking rate for availability checks
Staff portal 575K 1,308 staff × 20 views/day × 22 days
Queue & kiosk 144K 327 branches × 20 interactions/day
Calendar sync (event-driven) 660K ~30K ops/day vs 857K with naive polling
Admin portal 55K ~50 admins × 50 views/day
Webhooks & notifications 128K ~3 per booking (email, SMS, webhook)
External total 4.1M
+ Internal fan-out (1.5×) ~10M Edge gateway → domain Workers
D1 Database Operations & Storage
Metric Monthly Volume Notes
Row reads ~12.6M Availability, config, staff portal, admin
Row writes ~248K Bookings, calendar sync, admin updates
Config D1 ~50 MB 327 branches, staff, services, schedules
Ops D1 growth ~85 MB/mo 42.5K bookings × 2KB each
Year 1 total storage ~1.1 GB Config + first year of ops
Year 5 total storage ~5.2 GB Config + 5 yearly shards
Year 10 total storage ~10.3 GB Config + 10 yearly shards (~1GB each)
Real-Time & Durable Objects
Metric Volume Notes
Concurrent WebSockets ~1,962 ~6 per branch (queue board, devices, dashboards)
WebSocket messages / month ~4.3M ~100 messages/connection/day × 22 days
Booking lock requests ~42.5K One DO per booking hold
Queue messages (Queues) ~157K Notifications, webhooks, calendar sync
Projected Monthly Cloudflare Bill — HSBC UK
Service Year 1 Year 5 Year 10 Pricing Basis
Workers (compute) $5.08 $5.08 $5.08 $5 base + $0.30/M overage on 10M included
D1 (storage) $0.00 $0.15 $3.98 5GB free, then $0.75/GB. Reads/writes within free tier.
Durable Objects $0.55 $0.55 $0.55 ~4.5M DO requests/mo at $0.15/M
R2 (assets) $0.05 $0.05 $0.05 ~1GB stored at $0.015/GB + ops
Queues $0.06 $0.06 $0.06 157K messages at $0.40/M
Pages (frontends) $0.00 $0.00 $0.00 Free tier. Static assets on CDN.
Total $5.74 $5.89 $9.72
$5.74
HSBC UK / Month (Year 1)
327 branches, 1,308 staff, 42.5K bookings/mo
$500+
Legacy Equivalent
MySQL shard + Redis + ECS + Sidekiq + Pusher
87×
Cost Reduction
Active, fully-loaded tenant. Not idle.
$0.00
Idle Tenant Floor
No provisioned infra. Pay only for what you use.
Why this works
Cloudflare's model is fundamentally different from AWS. There are no provisioned servers, no reserved instances, no always-on clusters. Workers execute on-demand at the edge. D1 databases are SQLite files replicated globally—you pay per GB stored and per row touched. Durable Objects coordinate real-time state without a WebSocket server. Queues process messages without Sidekiq or Redis. Every component scales to zero when idle and scales up automatically under load. There are no capacity planning decisions, no over-provisioning for peak, and no infrastructure team required.
Built in a weekend.
Ready for what's next.
This is what happens when you pair deep domain expertise with modern AI-assisted engineering and an infrastructure platform designed for the next decade.
Back to Top Try the Booking Flow