Vertical presets configure notice, horizon, duration, capacity, buffers, deposits and approval without forking the scheduling core for each industry.
Public · Configurable booking platform
Booking
A multi-vertical booking platform that models appointments, capacity and stays as related scheduling contracts, with auditability, supply-chain security and engineering evidence built into the foundation.
- Niche
- Reusable booking with domain-specific rules
- Core stack
- TypeScript · web applications · verifiable CI
- Models
- Appointments · capacity · stays
- Focus
- Strict rules · auditability · configuration
System view
Business rulesAvailability engineBooking UIAudit evidence
The study
Barbers, clinics, restaurants and hotels share the concept of booking while operating under distinct rules.
The platform reuses scheduling infrastructure while preserving the specific model for a one-person appointment, a capacity-limited table and a multi-night stay.
System structure
Business variability is expressed through explicit models and configuration.
Three scheduling contracts
Appointment, capacity and stay models can enforce different duration, availability and occupancy rules.
Vertical presets, common core
Presets provide a recognizable starting point and share core infrastructure across sectors.
Governance from the start
Control registries, CODEOWNERS, security policy and retained evidence make engineering decisions auditable.
Inspectable supply chain
CodeQL, SHA-pinned actions, CycloneDX SBOMs and provenance manifests form a regular evidence trail for the workspace.
Product and interaction design
Configuration preserves the differences that make each business model valid.
The design separates the user-facing questions—what resource, when, for how many people and for how long—from the internal rules that determine whether a reservation is valid. The interface stays concise while domain rules remain explicit.
Configuration, operations and audit evidence are designed as understandable surfaces for operators and developers alike.
Architecture lens
The shared scheduling model is separated from persistence so a zero-infrastructure demo does not become an accidental production architecture.
Appointments, exclusive resources, pooled capacity and variable-length stays are evaluated by a pure scheduling engine. The browser persistence adapter is intentionally replaceable; a production multi-user service must atomically revalidate availability at the transaction boundary.
The MVP can persist locally, but production correctness is defined around atomic write-time availability validation rather than optimistic client state.
Control registries, evidence manifests, CodeQL, dependency gates and CycloneDX SBOM generation model operational assurance alongside application behavior.
Known gaps such as release reproducibility are recorded explicitly instead of being hidden behind tooling, keeping architecture documentation aligned with actual guarantees.
Development approach
The domain model is treated like a design sketch: something to challenge with real scenarios before turning it into reusable infrastructure.
Rules are checked deterministically and the repository preserves evidence about how each artifact was built. The foundation can grow toward transactional persistence and administration while preserving traceability.
A barber appointment, a restaurant table and a hotel stay act as concrete tests of the same platform. Abstractions begin locally and enter the shared core once they serve multiple verticals. Governance, security checks and retained evidence continuously verify the generalized behavior.
The working cycle is scenario → prototype → validate → generalize. It supports efficient exploration of unusual business rules while the shared platform stays coherent.