QZee

QZee began with a recognisable two-sided problem. Customers needed a clear way to find a service, trust that a time was genuinely available and finish a booking. Owners needed to describe what they sold, control when it could be booked and see the confirmed result in an operational diary. Solving either side alone would have produced another disconnected calendar or directory.

The scope expanded because real service businesses do not operate as a tidy list of appointments. A service can depend on a venue, staff member, add-on, group size, consultation answer, payment rule or closure. Availability can be entered manually or generated from recurring rules. A successful charge can still be followed by a failed booking write. Events introduce capacity, ticket quantities and different discovery behaviour, while owners still need the result to land in the same customer, transaction and notification model.

The product therefore became a connected operating system. The customer web app owns discovery and conversion. The owner product owns configuration and day-to-day control. Separate Customer and Business GraphQL boundaries protect the intent of each audience while sharing domain rules underneath. Jobs and integrations handle reminders, cleanup, migrations, imports, payment recovery and calendar coordination. Marketing, support and pricing explain the same capabilities before a user enters either application.

That growth created a second problem: consistency. The design-system repository records an internal audit finding of more than 4,000 hard-coded colour values, while its foundation documents identify two different live brand limes. QZee One was built in response, not as a cosmetic refresh. It turns product language, tokens, components, channel coverage and evidence into an inspectable operating layer for the whole company.

QZee One begins with semantic intent: what a colour means, what a control promises, how a status is communicated and which channels are required to support it. Web, native, email and marketing packages implement those contracts with their own accessible primitives. A registry links assets to owners and maturity. A CLI and fourteen automated quality gates in the release pipeline test the rules. The portal lets contributors inspect the same system without reading package source first.

The proposed architecture decision formalises an emerging contract-and-adapter model rather than a universal runtime that attempts to render one component everywhere. Shared pixels would hide meaningful differences in semantics, interaction, layout and platform capability. The emerging model accepts implementation work in exchange for clearer responsibilities and better interfaces in each channel.