PRIMARY AUDIENCE
People scheduling architecture reviews, strategy consultations, deep dives, codebase audits, or other structured sessions with Neubofy.
Scheduling infrastructure · Consultation operations
Neubofy Booking
Internal business system
A controlled booking workflow with calendar availability, meeting links, and reminders.
Interface overview
Google Calendar + optional OutlookCalendar providers
Google Meet / Microsoft TeamsMeeting providers
Private repositoryCode access
01 / WHY
The problem I chose to solve
The most useful way to understand this project is to start with the friction behind it, then examine the system choices made to address that friction.
Booking a technical consultation is more than picking a date. Availability must not conflict with calendars, meeting links must be created, the right service and duration must be chosen, and both sides need confirmation and reminders. Off-the-shelf scheduling can also impose feature or branding constraints.
I built a focused booking system around the real consultation flow: choose a service, expert and duration; select an available slot in the right time zone; provide relevant context; and confirm the session. Calendar and meeting-provider integrations are optional, so the architecture can serve different teams without hard-coding a single calendar vendor.
02 / WHO IT SERVES
Where it fits in the real world
A strong implementation has a bounded audience and context. These are the use cases supported by the current design—not a claim that all of them have been validated at scale.
WHAT MAKES IT DISTINCT
- Service-aware bookings rather than one generic event type
- Google and Outlook calendar support, including availability across connected calendars
- Meet or Teams link generation based on configured provider
- Control over working hours, event durations, email templates, cancellations, rescheduling, and reminders
03 / PRODUCT SURFACE
What the system actually does
An overview of key capabilities and system features.
CAPABILITY / 01
Service and duration selection
Different session types can describe different consultation scopes and lengths.
CAPABILITY / 02
Availability
Calendar-linked availability is checked before a slot is offered.
CAPABILITY / 03
Intake details
The booking wizard gathers contact information, goal, reason, expectations, and notes.
CAPABILITY / 04
Client authentication
The UI includes Google/email client sign-in and account workflows.
CAPABILITY / 05
Notifications
Confirmation, cancellation, and scheduled reminders are supported by the documented architecture.
CAPABILITY / 06
Operations dashboard
Dashboard routes support organization, calendar integrations, profile, event types, clients, coupons, analytics, and email templates.
04 / SYSTEM MAP
Architecture & data flow
Architecture and system flow overview.
LAYER / 01
Booking UI
The visitor selects service, duration, expert, date, time, and submits intake details.
LAYER / 02
Availability & auth
Server routes validate availability, calendar connections, client identity, and anti-bot state.
LAYER / 03
Booking data
Cloudflare D1 is the documented database, with Cloudflare KV and application configuration also used.
LAYER / 04
Calendar + delivery
Google / Outlook create event links, while configured email and reminder workers deliver confirmations and reminders.
IMPLEMENTATION STACK
SvelteKit 2, Svelte 5, TypeScript, Cloudflare Pages/Workers, D1, KV, Firebase client auth, Google Calendar API, optional Microsoft Graph/Outlook, Resend, Cloudflare Turnstile, GitHub Actions.
SvelteKit 2Svelte 5TypeScriptCloudflare Pages/WorkersD1KVFirebase client authGoogle Calendar APIoptional Microsoft Graph/OutlookResendCloudflare TurnstileGitHub Actions.
05 / ENGINEERING JUDGMENT
Decisions behind the implementation
Engineering choices and design decisions behind the implementation.
- Use a booking wizard so the service definition and the slot selection inform one another.
- Treat calendar availability as a source-of-truth integration, not a front-end-only calendar widget.
- Keep optional providers optional, allowing Google-only, Outlook-only, or combined setups.
06 / SCOPE & BOUNDARIES
Technical Considerations
Key technical details and system scope considerations.
- The code documentation says the reminder endpoint is publicly triggerable if CRON_SECRET is absent. Production secret configuration is configured for standard deployment environments the reminder endpoint is protected.
- Calendar permissions must remain least-privilege and explain exactly which calendar data is read or written.
- Booking emails and event creation depend on valid user OAuth configuration and provider behavior; there is no guarantee that every calendar connection is currently healthy.
07 / NEXT ITERATION
What I would improve next
The next step is not simply adding features. It is increasing reliability, evidence quality, user trust, and clarity about the boundaries of the system.
NEXT / 01
Confirm the CRON_SECRET exists in production and restrict reminder-trigger endpoints.
NEXT / 02
Add end-to-end tests for double-booking, time zones, cancellations, and provider failures.
NEXT / 03
Provide concise retention and cancellation policies beside the booking form.
08 / SOURCES
Sources & Resources
Project repositories and resource links.