6 original product implementations.

Template briefs

Choose by product structure, not decoration

Each template describes a different information architecture, customer task, and operating model. Start with the routes and states your product genuinely needs, then compare its content hierarchy, navigation depth, data density, and conversion path with the public brief. A matching colour palette is not evidence that a template fits the product. Teams should expect to replace every demonstration name, claim, image, metric, integration, and policy reference with reviewed material from their own source of truth.

The route contracts expose enough information to plan integration without revealing paid implementation. Inspect whether the proposed pages cover the real customer journey, where authentication or permission boundaries occur, and how loading, empty, error, success, offline, and denied states will be supplied by the application. The finished product remains responsible for its data model, server authorization, analytics consent, legal copy, support operation, and production monitoring.

What the status does—and does not—prove

An implemented record means the private repository contains the declared responsive source and automated evidence. It is not a customer release. Before any template can be sold or downloaded, its complete states must pass manual browser, keyboard, zoom, assistive-technology, dark-mode, reduced-motion, and RTL review. A versioned archive must then pass boundary inspection, receive checksums, enter protected storage, and be retrievable only through a current server-side entitlement. Until those gates are recorded, the public pages remain status reports rather than purchase promises.