01
Next.js 14 App Router with authenticated (app) shell, marketing pages, public /book/[slug], and client-portal routes
WorkServiceOS
Scheduling · Small service businesses2026
ServiceOS
A multi-teacher operations and booking product — appointments, clients, public booking pages, reminders, and a client portal.
- Project
- Product build
- Year
- 2026
- Focus
- Scheduling · Small service businesses
Overview
What this project set out to solve
ServiceOS (public repo: TheServiceOS) is built for independent instructors and small service businesses that schedule lessons or visits. It replaces spreadsheet-and-WhatsApp chaos with one place for calendar, clients, booking requests, branded public booking links, and reminders — Hebrew-first and RTL-ready.
Our role: Product design and full-stack SaaS delivery — App Router architecture, Supabase data model, auth sessions, booking flows, reminders, client portal, and launch-ready marketing shell.
Business challenge
The operational problem we designed around
Small service businesses — driving schools, clinics, and similar verticals — often run scheduling over phone calls, spreadsheets, and WhatsApp threads. Availability is hard to publish, booking requests lack a clear approval path, and reminders fall through the cracks.
Give teachers and staff one authenticated operations shell for appointments, clients, and availability — while end customers book through a public slug URL without logging in.
Hard parts of the problem
- 01Keeping slot generation correct across availability, blocked dates, and overlapping appointments
- 02Multi-teacher tenancy with per-teacher public slugs and session-scoped listing
- 03Reminder delivery across WhatsApp, email, and optional cron without brittle provider coupling
Solution
How the product solves it
We built ServiceOS as a Next.js App Router product on Supabase: public booking via /book/[slug], staff approval of booking requests into appointments, availability and blocked dates for slot generation, in-app notifications, WhatsApp-oriented reminders, optional email via Resend, Stripe integration points, a client portal, and PWA/offline support.
- 01Public booking pages per teacher slug — customers pick a slot and submit a pending booking
- 02Authenticated app shell for appointments (calendar), clients, teachers, and availability settings
- 03Booking request approve/reject flow that maps into appointments
- 04Reminders with WhatsApp helpers, optional Resend email, and Google Calendar integration points
- 05Client portal for customer signup, booking, reschedule, and payment history
- 06PWA support with an offline page for more resilient mobile use
Architecture
How the system fits together
02
Supabase as the data layer — anon browser client plus service-role admin on the server
03
Session cookies validated against a sessions/teachers model for staff auth
04
Slot generation from availability settings and blocked dates
05
Reminder and messaging hooks (WhatsApp helpers, optional Twilio, optional OpenAI reminder drafts)
06
Stripe libraries for payment integration points; Resend for transactional email
Technology stack
Tools chosen for the problem
Next.js
TypeScript
React
Tailwind CSS
Supabase
Stripe
Resend
PWA
Screenshots
Selected frames from the product
Development process
How the build moved forward
- 01
Defined the product around teacher operations and customer public booking — not a generic CRM
- 02
Modeled appointments, clients, teachers, availability, and booking approval in Supabase
- 03
Shipped the public booking flow and staff approve/reject path first
- 04
Added reminders, notifications, analytics dashboard widgets, and client-portal auth
- 05
Hardened auth/session edge cases and prepared Vercel deployment with env-based secrets
Lessons learned
What this build taught us
- 01Public booking only works when availability and blocked dates stay the single source of truth
- 02Hebrew-first RTL products need vertical-aware labels from day one — not a translation pass at the end
- 03Separate staff auth from client-portal auth early; shared tables with different session models stay clearer
Work shown is product and systems engineering — outcomes vary by scope and constraints.
Strategy
Want a build like ServiceOS for your workflow?
Share the bottleneck in your business. We’ll map a comparable first phase — written scope, weekly demos, no invented promises.
More product builds
