Buku: booking infrastructure as a product system
A case study in modelling customer intent, staff capability, business availability, and operational follow-through as one coherent booking domain.
Personal product under active development.
From service intent to observable appointment
The first release treats booking as one coordinated decision across capability, time, and business operation.
Capture the complete request
Business, services, staff preference, and timing begin as one booking intent instead of unrelated selections.
The domain is a coordination problem
Product definition and architecture across backend services, customer and business mobile applications, a web experience, administration workflows, authentication, scheduling, media, reviews, notifications, and business-management features.
- R1
Customer
Discover a business, choose services, select an eligible staff member and time, then manage the appointment.
- R2
Staff
Work within service-specific skills, availability, schedules, and appointment responsibilities.
- R3
Owner
Configure services, people, opening rules, media, reviews, and the operational view of the business.
- R4
Administrator
Oversee platform-level workflows and the boundaries between customer and business experiences.
The first release follows one legible booking path
STEP 01
Express intent
A customer chooses the business and one or more services.
STEP 02
Resolve capability
The system connects each service to eligible staff and service-specific availability.
STEP 03
Sequence time
Multi-service booking is treated as a sequential scheduling problem for the first release.
STEP 04
Confirm operation
The appointment becomes visible to the customer, staff member, business, and administration workflows.
One booking domain, four operating layers
The boundaries keep customer intent, business configuration, domain rules, and infrastructure understandable without pretending they are independent products.
L01
Product experiences
- Customer app
- Business app
- Web
- Administration
L02
Domain services
- Booking
- Staff
- Business
- Reviews
- Notifications
L03
Data and coordination
- PostgreSQL
- PostGIS
- Redis
- Media
L04
Delivery boundary
- Go services
- Role access
- AWS
- Observability
Decisions are useful when their constraints remain visible
Defined the platform architecture and core booking workflows across customer, business, and administration experiences, with the backend and application foundations under active implementation.
- D1Go backend with PostgreSQL, PostGIS, and Redis
- D2Separate customer, business, and administration experiences
- D3Next.js web application and React Native mobile applications
- D4Multi-service sequential booking for the MVP
- D5Staff skills and availability by service
- D6Role-based access across customer, staff, owner, and administrator contexts
- D7Albanian-first internationalization with English support
Questions that keep the architecture honest
- Can the booking rules be explained without reading implementation code?
- Can staff capability and availability change without rewriting the customer flow?
- Can each experience expose only the actions its role owns?
- Can production failures be traced across the booking lifecycle?
Current product progress
Completed
Monorepo, shared packages, and local infrastructure established
Completed
Core booking, staff, business, and administration workflows defined
In progress
Customer and business experiences under active implementation
Planned
First hosted end-to-end release
Have a product or engineering challenge to discuss?
I am available for selected product development, consulting, and senior engineering engagements.
Or write directly to laerti98@gmail.com.