Base Blu Training Club
A distinctive club website that keeps its own voice while using QZee as the operational truth for services, availability, identity and reservations.
- Role
- Product architecture, UX, interface and integration
- Brand owner
- Base Blu controls proposition and editorial content
- Operating system
- QZee controls services, customers, slots and bookings
- Repository
- QZee-Ltd/base-blu-web · production status qualified
Make the website feel independent without making the data independent
Base Blu needed a site with the confidence and visual character of a specialist training club. It also needed customers to understand classes, inspect prices, find current sessions and reserve a place. Rebuilding those operational records inside a content system would have created two class catalogues, two calendars and an avoidable reconciliation problem.
The resulting architecture separates presentation ownership from operational ownership. Base Blu owns its proposition, editorial hierarchy, photography and customer-facing tone. QZee remains the source of truth for venue data, services, durations, prices, slots, customer identity, consultation or waiver questions, holds and confirmed bookings. The customer experiences one coherent journey, but the implementation never pretends the club website is the booking ledger.
QDev designed and implemented the website, integration and transaction flow in the QZee-Ltd/base-blu-web repository. The live public site and reviewed code support the capabilities described here. The repository contains Render deployment configuration, but the current production commit was not independently reconciled during this publication pass, so production status is intentionally qualified rather than overstated.
Brand, integration and booking were designed as one release
2026 · Model
Assign ownership before designing screens
Defined which content belongs to Base Blu and which records remain owned by QZee, including venue, services, availability, identity and bookings.
2026 · Editorial
Create a club-specific public experience
Built the proposition, class comparison, pricing, timetable and supporting pages around Base Blu's own information hierarchy.
2026 · Transaction
Implement the route to fresh QZee state
Added authenticated booking with fresh slot checks, holds, conditional questions, confirmation and timetable revalidation. Authenticated runtime capture remains pending.
14 July 2026
Capture and qualify the live state
Recorded the public site and checked the repository-backed integration. Production lineage remains pending a commit-level reconciliation.
The branded layer, operational layer and seams between them
Capability status definitions
- LiveAvailable in a public or deployed product.
- ImplementedBuilt, but release or approval is not evidenced.
- DemonstrationA labelled example using simulated data.
- ExploratoryResearch, specification or prototype only.
Editorial product site
A Base Blu-owned experience for the club proposition, classes, pricing and action paths.
- Brand and proposition
- Class education
- Pricing and timetable routes
- Responsive public pages
RepositoryQZee-Ltd/base-blu-web
Public QZee reads
GraphQL data keeps public service information aligned with the operating product.
- Venue and class records
- Descriptions and duration
- Current prices
- Timetable presentation
RepositoryQZee API
Authenticated booking
Repository evidence maps the transactional route from a fresh slot to a confirmed QZee reservation.
- Customer Firebase identity
- Fresh availability query
- Temporary slot hold
- Confirmed booking write
RepositoryBase Blu web + QZee API
Conditional forms
Venue-configured consultation or waiver questions appear only when required for the reservation.
- Question retrieval
- Conditional booking step
- Authenticated answer submission
- Reservation context preserved
RepositoryQZee booking contract
Resilience layer
Public pages can remain useful during a read failure without allowing fallback data into a transaction.
- Cacheable editorial reads
- Public-content fallback
- Dynamic booking route
- Post-booking timetable revalidation
RepositoryQZee-Ltd/base-blu-web
Request and contact routes
Non-standard interest can return to QZee-linked workflows instead of becoming an untracked inbox fragment.
- Request-a-slot path
- Contact submission
- Venue context
- Server-mediated writes
RepositoryBase Blu web + QZee API
The interface changes ownership without making the customer feel the seam
From class research to confirmation
- ChooseUnderstand a class, then request current QZee availability.
- IdentifySign in or create the QZee customer identity used for booking.
- PrepareHold the slot and answer venue-set questions when required.
- ConfirmWrite the reservation to QZee and refresh the public timetable.
Editorial pages can tolerate cached or fallback content. Slot selection and booking do not use that fallback path and must resolve fresh transactional state.
Inspect booking (opens in a new tab)The public layer over operational truth
Live class and pricing views show how the club's editorial voice and QZee service records become one customer-facing product.
The integration choices that prevent drift
Keep QZee authoritative
- Decision
- Read operational class and booking state from QZee instead of copying it into the website CMS.
- Why
- Prices, availability and reservations must agree with the system the venue uses to operate.
- Consequence
- Base Blu can own presentation without maintaining a second catalogue, calendar or customer store.
- Tradeoff
- The public experience depends on a clear integration contract and considered failure handling.
Split editorial freshness from transactional freshness
- Decision
- Allow cache and fallback for public explanation, but force fresh reads for slot selection and booking.
- Why
- A useful class description can survive a short service interruption; a stale available slot cannot.
- Consequence
- The public site remains resilient without disguising uncertain inventory as bookable capacity.
- Tradeoff
- The application maintains two deliberate data policies instead of one universal fetch strategy.
Respect the venue timezone
- Decision
- Interpret and present timetable state through a venue-aware timezone helper.
- Why
- A class is a local appointment, and server or visitor timezone defaults can shift the apparent day or time.
- Consequence
- Research, selection and confirmation can refer to the same local session.
- Tradeoff
- Date handling requires explicit conversion and tests around daylight-saving changes.
Use a server hop at the integration edge
- Decision
- Mediate selected GraphQL operations through the application server rather than exposing every external request directly to the browser.
- Why
- The boundary needs controlled inputs, predictable cross-origin behaviour and a place to keep sensitive handling out of client logs.
- Consequence
- The website can constrain requests and avoid logging customer details while still using QZee services.
- Tradeoff
- An additional application boundary adds latency and must preserve errors accurately for the interface.
Reuse QZee customer identity
- Decision
- Authenticate the reservation with the existing QZee Firebase customer rather than issue a Base Blu-only account.
- Why
- The booking and customer record already belong to QZee, and duplicate identity would create reconciliation work.
- Consequence
- A customer can move from the club site into an authenticated booking without another user database.
- Tradeoff
- Authentication errors and recovery need to feel native to Base Blu while following QZee rules.
Two products, one controlled integration boundary
Live surface from the club product repository
Base Blu public site
LiveOwns Base Blu's editorial interface, proposition, class presentation and public booking entry points.
- Next.js App Router
- TypeScript
- Tailwind
- Render
The public site and dated captures are inspectable. Its exact production commit has not been reconciled.
Repository-backed transaction boundary
QZee-Ltd/base-blu-web booking integration
ImplementedOrchestrates authenticated availability, holds, conditional questions, reservation writes and timetable revalidation.
- Next.js App Router
- TypeScript
- QZee GraphQL
Reviewed code supports the complete path. An approved authenticated runtime capture and production-commit reconciliation remain missing.
Operational product service
QZee API
LiveRemains authoritative for the venue, services, prices, slots, holds, questions, customers and confirmed bookings.
- GraphQL
- Booking domain
The integration is directly evidenced in the Base Blu repository. QZee is maintained as a separate product boundary.
Shared authentication boundary
QZee customer identity
ImplementedAuthenticates the customer used by the reservation and keeps identity attached to the QZee booking record.
- Firebase Authentication
Identity reuse is implementation-backed. This case does not claim an independent authentication or security audit.
A club-owned experience without a second source of truth
Base Blu presents its training offer with a distinctive voice while public operational facts continue to come from QZee. The implemented booking path moves from proposition to class, current session, identity, required questions and confirmation without creating another calendar or customer database to reconcile.
The next evidence step is to bind the live deployment to a verified commit and publish approved measures such as booking completion or fallback frequency. Those outcomes are deliberately absent until the evidence exists.
Make your site part of the product.
Connect your brand, operating data and customer journey through a product build designed to stay in sync.
Discuss a project