This page describes everything the DomiDo platform must do. Where the software overview explains what the system is, this page explains what the system does, walking each domain in turn: the shared application shell that every surface inherits, multilingual handling of user-generated text, OAuth-based authentication, public discovery on the home and gallery, the listing detail page, the five-stage create wizard, the Phase A interest-reservation flow, the cart and Stripe checkout, the buyer dashboard and the orders that live inside it, the designer-side listing and Promo Studio surfaces, designer payouts and tax, the Help and Workshop content layer with its discussion records, and the operational behaviour that governs jobs, errors, analytics, and beta dashboards. Every behaviour on this page is interpreted through the delivery-phase model. Mandatory acceptance today is on the Web desktop surface; mobile web, iOS, and Android behaviour remain compatible through the universal app architecture and become mandatory only when later phase gates open. Future-phase surfaces visible in the mock stay blocked, read-only, waitlisted, or coming-soon until their phase is active, and a visible control never implies active money movement, pre-order, fulfilment, shipment, payout release, or remix economics unless the corresponding phase is active.
Every surface on DomiDo sits inside a shared application shell that supplies a global header, a global footer, modal and sheet behaviour, and the toast or inline status feedback that runs through every long action. The global header carries brand navigation, primary surface links, search entry, a language selector, authentication and account entry, cart entry, and the mobile drawer behaviour. The language selector exposes the backend-configured language options; mock language labels are examples and never hard-coded as product truth, and the same configured language set acts as both the user-interface locale options and the target-language set for translatable user-generated content where translation is enabled. The footer exposes configured locale and currency choices, social links, the sitemap, the data-request link, the Manage cookies entry, the newsletter signup, the legal and help links, and the locale controls themselves.
Modal and sheet behaviour — open, close, focus management, backdrop handling, and the escape key — is shared across authentication, search, every enabled navigation surface, cart, help, payment retry, order actions, admin help-content forms, and account forms, so the user experience does not splinter across surfaces. The application also provides toast or inline status feedback for save, publish, upload, generation, model feedback, interest reservation, Phase A.5 checkout, order, return, trust restriction, payout, help-content administration, and settings operations, so every action produces a visible result instead of leaving the user guessing.
Every mutation that stores free-form user-generated text submits or infers a source language and preserves the original user text exactly as the user wrote it. The backend then asynchronously translates translatable user-generated text into every configured supported language and exposes the pending, complete, failed, and stale translation status to editor, admin, support, dashboard, and moderation surfaces wherever that state is useful. Public and signed-in read responses resolve text fields to the requested language using a deterministic precedence — an explicit API language parameter where present, then the user's preferred content language, then the Accept-Language header, then the configured fallback order, and finally the source text — so every consumer of a translated field sees the same resolution result for the same inputs.
Structured and sensitive fields are never sent for translation. Names, email addresses, phone numbers, postal addresses, payment data, file names, identifiers, Value-Added-Tax or tax identifiers, OAuth profile data, and credentials all stay off the translation path regardless of which calling resource happens to have them. Translation failures never block saving the source content; the user interface stays usable with source-language fallback and may show a retry or status indicator on owner and admin surfaces where that visibility helps.
The authentication modal exposes OAuth sign-in for Google, Apple, and Facebook only; no other provider may appear without an approved product requirement. The modal supports sign-in and sign-up mode switching where the surface displays both modes. When a user completes the OAuth flow, the system creates or updates a user profile from the OAuth identity data and associates that profile with the user's drafts, saved listings, interest reservations, Phase A.5 carts, checkout and pre-orders where active, orders where active, listing-owner and designer state, admin capability where applicable, and account settings, so the signed-in identity carries every capability the account is authorised for without needing separate sign-ins per role.
The home surface carries a create-upload entry that communicates GLB, GLTF, OBJ, and STL model support and the one-hundred-megabyte upload limit, so creators see the input contract at the moment they decide to upload. Upload validation rejects every format outside that allowlist; raster and reference media slots inside the create flow retain their own validation and normalisation behaviour. The home composition exposes a gallery rail, creator and listing-owner discovery where active, public user-owned designs, and newsletter affordances.
Search is reached from the header and from the search modal, and it covers configured scopes — listings, creators and listing owners where active, Help and Workshop content, and any other scope enabled by configuration. Each search result carries a type, scope, title, summary or snippet, thumbnail, avatar or swatch metadata where applicable, target URL or resource reference, scope count, match-highlight data where provided, and result-specific metadata for listing, creator, and Help cards. Recent search terms are persisted locally for the active browser profile, and they can be shown and cleared without requiring backend storage. Voice-search affordance and listening or waveform state may be shown only when both the browser or device capability and the product configuration support it; typed search remains the baseline path. Gallery browsing supports listing cards, the saved state for the viewer, the filtering and sorting affordances visible in the mock, and navigation to the listing detail.
The listing detail renders the listing's media, title, owner and creator identity, an indicative price or a price-unavailable state where configured, future royalty or markup context only where phase-active, jurisdictional Value-Added-Tax copy only where phase-active, the assembly and kit summary, reviews and questions where visible, save, share, and report actions, and related or similar listing affordances. Alternative product-detail mock surfaces are preserved as documented user-interface variants rather than collapsed into one inferred production status. In Phase A the listing detail offers a non-binding interest-reservation call-to-action instead of an add-to-cart control; add-to-cart and pre-order controls remain hidden, blocked, or replaced by invitation-only Phase A.5 conversion controls until their phase is active. The listing also supports owner and creator attribution, follow and save actions where active, creator-profile navigation where active, and Phase A disabled-remix messaging wherever remix affordances would otherwise appear. Assembly information and the bill-of-materials-derived summaries required by the buyer experience are exposed in line with the rest of the detail.
The create flow runs through five stages — Describe, Projections, 3D model, Block kit, and Save and publish — and it remembers where the creator was. When the user enters the wizard, the system loads any saved draft or generation state on entry and offers a way to continue or to intentionally start a new draft.
The Describe stage supports the title and brief fields, reference text, supported model and source media upload, preview and crop state where applicable, category, tag suggestions, selected tags, labelled prompt suggestions, and validation feedback. It also supports a style-reference gallery; selecting a style preset updates the prompt with the preset descriptor and sets a reference image or thumbnail without discarding the user's existing prompt content, unless the prompt is empty and the preset supplies a seed prompt. Style presets are served as configuration with a label, palette, descriptor, seed prompt, swatches, and a thumbnail or reference media; the frontend does not hard-code the preset list. Media validation state is stored throughout, covering the accepted format, the rejected format, the too-large file, the crop frame where applicable, the normalised raster output where applicable, the source filename, and the configured one-hundred-megabyte upload size limit.
The Projections stage supports face slots for the front, back, right, left, top, and bottom views; the front is compulsory and the rest are optional. Each face supports a source media reference, a generated preview, an active or inactive state, per-face history, a restore action, a regenerate action, source reuse, zoom state, and optionality metadata. The stage supports optional autofill of missing non-front faces, and it indicates which faces are generated as opposed to user-provided or restored.
The 3D model stage supports the generation options, the configurable AI-generation cost display, progress, errors, tryout history, the selected tryout, statistics, and GLB or GLTF-compatible output references. Model tryout records include the option name, the created time, the status, preview or reference media, the output size label where shown, the statistics visible to the UI, and the user-feedback state. The stage allows the user to submit feedback on generated model quality, including a rating or assessment, issue categories, an optional comment, and the usability decision.
The Block kit stage shows the configurable generation cost before generation runs — it never hard-codes a fixed credit value — and supports generation progress, the result preview, Bill-of-Materials search, filter, and grouping, the Stock-Keeping-Unit count, the part count, the estimated cost, the estimated build time, the assembly step payloads, and the retry and error state.
Save and publish supports the visibility values private, unlisted, and public. It supports the ownership and licence acknowledgement, the intended-use and safety gate, the Phase A disabled-remix messaging, future royalty and entitlement controls only where phase-active, draft save, and the publish action. Publish validation requires title and brief, supported media, the compulsory front projection, a selected model, a block kit, the visibility setting, the ownership and licence acknowledgement, the intended-use and safety data, and the listing metadata before public publication; Phase A publication does not require price or royalty setup.
The Phase A listing detail exposes an interest-reservation call-to-action for eligible public listings and does not require card, address, cart, or checkout data. The flow shows an explicit acknowledgement that the action is non-binding, creates no pre-order, order, or purchase, charges no money, and promises no fulfilment date. Creating an interest reservation is idempotent per user, per session, and per listing while an active reservation already exists, so retries never inflate demand. Users can view and cancel their own active interest reservations from dashboard surfaces. Founder and admin surfaces show reservation demand by listing, owner, source, user or session, geography where known, cancellation state, and Phase A.5 qualification state. Phase A.5 conversion requires a separate invitation and a fresh buyer action; the application never automatically converts an interest reservation into a SetupIntent pre-order.
Cart is not a Phase A interest-reservation requirement: wherever cart UI is visible in Phase A, it is disabled, hidden, or redirected to reservation semantics. In Phase A.5 and Phase B the cart supports listing line items, quantity changes, remove, saved-for-later where visible, the price summary, the delivery and Value-Added-Tax summary, the promo entry where visible, and checkout entry. Saved cart and checkout-draft management is Phase A.5 and Phase B active; it supports save-bag-for-later, the list of saved carts, item count, summary, last-updated and selected checkout step, resume checkout, discard saved cart, and stale-item, unsupported-jurisdiction, unavailable-delivery, or recalculated Value-Added-Tax and total validation before the buyer continues.
Checkout uses Bag, Delivery, Payment, Review, and Confirmation surfaces only in Phase A.5 and Phase B, or where a future-phase surface is explicitly blocked or read-only; Phase A demand capture uses the interest-reservation surfaces. Delivery supports saved addresses, address editing, manual entry, supported-jurisdiction validation, and validation feedback. Jurisdiction configuration determines whether a buyer may continue Phase A.5 or Phase B checkout; unsupported jurisdictions show coming-soon copy and block payment, while Phase A may still collect interest if the listing and jurisdiction policy allow non-binding demand capture. Delivery also exposes jurisdiction-configured methods with labels, descriptions, pricing, delivery-window copy, and collection-point requirements where available. Payment is absent from Phase A interest reservations entirely. Phase A.5 payment supports Stripe-handled SetupIntent card verification for invited eligible reservations only, and Phase B payment supports Stripe-handled card capture, billing details, and Stripe payment status; payment copy lists only card types Stripe supports in the buyer's jurisdiction and never exposes non-Stripe payment methods. The Phase A.5 review step shows jurisdiction-dependent Value-Added Tax where applicable, delivery or future-delivery assumptions, the item total, the expected final total, the supported-card copy, the Stripe SetupIntent state, and a no-capture acknowledgement for invited physical-kit pre-orders; Phase A reservation confirmation shows no payment state. Checkout and confirmation do not show or depend on a post-checkout manual queue or wait-time metric.
The confirmation surface is phase-specific. A Phase A reservation confirmation exposes the reservation reference, the non-binding and no-charge acknowledgement, the cancellation path, the next steps, and navigation to the dashboard. A Phase A.5 confirmation exposes the pre-order reference, the SetupIntent and card-verification state, the no-capture acknowledgement, the cancellation path, the gate summary, the next steps, and dashboard navigation. A Phase B confirmation exposes the order reference, the fulfilment state, the next steps, the receipt and invoice access where visible, and order-dashboard navigation. Phase A.5 and Phase B checkout mutations use typed checkout request data for delivery, payment, Stripe SetupIntent or session creation, the promo code, review validation, and confirmation; Phase A interest-reservation mutations use typed reservation request data; the user interface never submits opaque free-form payloads for these visible steps.
The buyer dashboard lists Phase A interest reservations, Phase A.5 no-capture pre-orders, and Phase B orders, each with status, item summaries, payment state where active, fulfilment or future-readiness state where active, notification counts, needs-action reasons, and detail navigation. The detail sheets specialise by phase: a Phase A reservation detail exposes the non-binding and no-charge acknowledgement, the listing and owner summary, an indicative price where available, cancellation, support, and Phase A.5 invitation state; a Phase A.5 pre-order detail exposes the SetupIntent and card-verification state, the no-capture acknowledgement, the expected price, cancellation, support, and the gate-and-timeline details; a Phase B order detail exposes payment retry through Stripe, the charge, jurisdictional Value-Added Tax, refund, receipt, invoice, delivery, fulfilment readiness, and the timeline details.
Phase A reservations and Phase A.5 pre-orders do not enter shipment or delivery states. Phase B orders support immediate fulfilment, waiting for missing stored blocks, and production-readiness waiting with no promised ship date and email notification when the order is ready to ship. Phase A reservations and Phase A.5 pre-orders support cancellation where state permits, support contact, and message-and-history views; Phase B orders additionally support address change, delivery-preference change, returns, replacements, issue reports, disputes, and payment retry where visible. Return handling supports fee and deduction assessment when returned blocks are damaged, show wear, are returned for change of mind, or have diminished value. The trust pipeline supports blacklisting or restricting a user for customer-extremism or anti-abuse reasons, and the affected user can challenge through support tickets or disputes. Receipt and invoice records are Phase B fulfilment artefacts and include tax, charge, refund, and masked Stripe payment-reference details; Phase A reservations and Phase A.5 no-capture pre-orders never expose receipts or invoices as if money has been captured. Buyer settings support saved addresses, saved Stripe payment references, communication preferences, privacy controls, and the account and security controls visible from the dashboard.
The buyer order-update inbox shows notification items with severity, unread or read state, timestamp, the linked resource or action target, call-to-action metadata, mark-read, and mark-all-read behaviour. The order detail also exposes typed shipment and tracking detail where known — shipments, parcels, parcel-item grouping, safe tracking reference or display, tracking stops, ETA deltas, the delivery option, and tracking messages; carrier names, ETA values, and tracking stops are record data, not hard-coded requirements. Delivery-preference changes use typed safe-place, neighbour, hold or collection, signature, and instruction fields where enabled by the order state and the delivery configuration. The side-sheet actions — cancel, payment retry through Stripe, address change, delivery preference, return, replacement, report issue, dispute or challenge, and support or message submission — all use typed request and response payloads, each exposing eligibility, validation messages, attachment references where enabled, result status, timeline update, and idempotent retry behaviour. The build companion is Phase B active and is reachable from an active fulfilled or fulfillable order and from a QR or open-from-order entry point; it provides assembly step payloads, progress saving, pause and resume where supported, stuck-help support escalation, finished-build photos, profile sharing, designer-feedback permission, and a separate build-experience rating.
The listing-owner and designer editor supports the listing's identity, title, description, category, tags, media, Bill-of-Materials and assembly data, visibility, status, the disabled Phase A remix state, and the publish and update actions; royalty percent, price derivation, and payout-related controls are Phase A.5 and Phase B gated. Royalty percent is constrained to zero through twenty-five wherever the listing-owner UI exposes the slider in an active future phase, and the listing editor calculates the buyer-facing retail price from the base kit price and the selected royalty percent only where the future-phase control is active, with designer royalty and entitlement values inclusive of Value-Added Tax where applicable. The listing right column supports ad-boost configuration where visible, with configured budget bounds and spend recorded in the statement and earning context. The editor also exposes status notices, performance metrics, messages, the disabled remix-action states, and the action items visible in the designer dashboard.
Designer listing editor responses include the owner-edit state, dirty or unsaved state, version or last-saved metadata, editable-versus-platform-read-only section metadata, save, apply, and discard actions, and the unsaved-leave guard state. Designer listing moderation exposes the clear, flagged, and blocked states, the moderation flags, safe evidence references, visibility restrictions, the configured rerun cost and eligibility, and the rerun job state without hard-coding a fixed credit cost. Designer listing similarity exposes similarity matches, uniqueness warnings, the gating state, and the publish or update restrictions where those states are visible. Designer listing analytics expose the section-level and listing-level metrics used by the right column, including views, saves, order and conversion signals, ad spend and performance, and acquisition guidance where configured.
Designer listing Hero authoring exposes a Promo Studio launch only for the listing owner or an authorised designer-management role. Promo Studio opens as a full-screen wizard with Stage, Photos, Video, and Library steps, step-rail counts, close and Escape behaviour, back-next-done navigation, toast or inline status feedback, and a credit-and-cost summary supplied by configuration. The Stage step allows the designer to configure the scene environment, the custom HDRI or reference-environment upload where enabled, the lens, horizon and sun state, the model's position, scale, rotation, and yaw, and the camera-rig state; it shows a source render preview and supports resetting the scene to defaults. The Photos step allows the designer to edit a prompt, append listing tags, choose a configured photo style, start a photo-generation job, view generated photo results, keep or star a result, animate a result as a video source, download a result, and add a result to the listing gallery. The Video step requires at least one generated photo before generation; it supports source-photo selection, motion-prompt editing, motion-prompt chips, configured duration choices, configured aspect choices, video generation, play and pause preview, keep and star, download, and add-to-listing actions. The Library step shows generated photos and videos with All, Photos, Video, and Starred filters, counts, empty states, download-all where authorised, per-asset keep and star, per-asset download, animate-from-photo, add-to-listing, and archive or remove where implemented. Promo Studio generated assets remain private to the listing owner until added to listing media, and adding an asset to the listing gallery updates the listing's media state and records the asset's published or gallery state.
Designer review-response workflows support opening a review-reply dialog, drafting a response, using configured assistive draft, polish, and shorten actions where enabled, saving the draft, posting the reply, updating or deleting the reply where allowed, and preserving the moderation and report context. Designer question-and-answer workflows support answering a listing question, saving a draft answer, posting or updating the answer, marking the designer or verified context, and creating an FAQ candidate from a question-and-answer pair without mutating admin-managed Help content. Designer message and claim workflows support message-thread lists, unread, pinned, priority, and status signals, threaded replies, internal notes where visible, message reports, support escalation, and typed claim actions — approve replacement, refund instead, request more photos, and escalate to platform support.
The Phase A dashboard may expose attributed interest demand for listing owners. The Phase A.5 designer dashboard exposes attributed no-capture pre-orders, projected sales, projected earnings or entitlements, payout readiness, configurable fees, statement previews, the Stripe Connect and Know-Your-Customer state, the reserve-and-dispute model, and payout activity where available. Phase B adds captured sales, payout-due amounts, payout history, payout request actions, and the payout-release events themselves. Designer payout settings support the Stripe Connect connection state and the identity and Know-Your-Customer state in Phase A.5 before Phase B fulfilment is enabled; payout settings clearly state that routing, account, and tax-identifier data stay with Stripe wherever that separation is shown. Tax settings support the Value-Added-Tax number, the Unique Taxpayer Reference, configurable tax-region choices, statement downloads, and the transaction-record retention copy visible in settings.
Payout options, schedule labels, pause-and-resume availability, the minimum payout threshold, the payout fees, the payout labels, grace-and-hold copy, and eligibility delays are all backend-configurable. Payout on request applies a configurable fee defaulting to two percent when payout release is eligible; in Phase A.5 the action may be configured and previewed but does not release funds before Phase B capture and delivery eligibility. Payout below the configured minimum amount applies a configurable fee defaulting to two percent when payout release is eligible; in Phase A.5 this rule is part of payout readiness and statement preview only. Projected entitlement can accrue from Phase A.5 attributed no-capture pre-orders when owner terms are active, but payout release eligibility starts no earlier than thirty days after Phase B delivery. Phase A interest reservations do not accrue payable royalties. The royalty rules do not encode a per-block royalty amount, a flat under-block minimum, a fixed monthly payout date, or a fixed reversal window as product truth.
Designer and listing-owner sales support attributed-interest states in Phase A, attributed-pre-order and reserved states in Phase A.5, and sold, disputed, and refunded states in Phase B wherever those states are present; sale detail shows lifecycle milestones for verified, captured, cleared, bundled-into-payout, and paid when those values exist. The Stripe Connect state supports not-connected, action-required, active, and first-sale or new-designer empty states; the action-required state shows requirements using safe labels and routes the designer to Stripe-managed remediation without exposing sensitive provider payloads. Payout balances distinguish available, pending, in-transit, and reserved amounts where present, and the pending and reserved explanations derive from configuration and sale-and-dispute state. Payout transfers support paid, in-transit, failed, and other configured statuses; a payout row may expand to show the included royalty events and supports failed-payout resolution or retry through an authorised Stripe handoff. The reserve ledger shows hold and release entries, linked sale or dispute references, the reason, the amount, the status, the totals, and the configured explanation text; reserve percentages, caps, release timing, and provider fee values are configuration, not fixed mock facts. Designer dispute views show the dispute reason and state, the disputed amount, the reserve impact, the platform-handling status, the win-or-loss outcome copy, and the royalty or statement impact when available; provider dispute-tool names and provider fees are configurable or omitted. The payout activity feed shows payout-paid or failed events, reserve-hold-or-release events, and dispute-opened events, links each to the relevant payout or sale or dispute, and supports notification-preference management. Tax-statement export supports selecting a configured tax year or period and an export format without exposing full tax identifiers in the user-interface state.
Help and Workshop surfaces expose Docusaurus-generated published help content with searchable content and configured general topic and category groups; the category names shown in the mock are content-metadata examples, not fixed functional requirements. The hub supports general topic groups, article-kind filters, article metadata, search snippets, featured and popular article slots, related navigation, backlinks where used, a table of contents where used, and support entry points. Published article rendering and navigation are compatible with Docusaurus static output. Specific article slugs, article bodies, shipping windows, material facts, designer-application statistics, and journal or story copy are managed content, not fixed requirements, and approved content is publishable into the Docusaurus public site. Only administrators can create, update, publish, unpublish, archive, delete, or reorder Workshop and Help content; the admin publication controls govern the Docusaurus-generated public projection.
Help article discussion supports user comments, replies, likes, helpful-and-newest sorting, role tags, a disabled empty-composer state, report and moderation status where enabled, and an empty discussion state. Help comments, replies, likes, and reports are user-generated discussion actions; they are not classified as Workshop or Help content mutation, and they do not grant non-administrators the ability to create, update, publish, unpublish, archive, delete, or reorder articles, topics, or kinds. Docusaurus public pages are not the system of record for comments, reports, support conversations, moderation state, or audit events; those runtime records live in the backend and admin workflows and may be embedded into or linked from Docusaurus pages.
Legal and privacy surfaces expose terms, privacy, accessibility, cookie management, the data-request link, the sitemap, and footer legal links. Cookie preferences support manage, save, and later update-or-revoke behaviour. Privacy settings support account data and marketing or notification controls visible in the account and dashboard mock. Account lifecycle and security settings support profile updates, avatar upload or removal, password and session controls where applicable, two-factor state where applicable, data-export request and status, pause-account or pause-shop request, and delete-account request and status as visible in the mock.
All mutating actions return user-interface-ready status, validation messages, and the updated resource snapshot needed by the initiating surface, so the calling screen never has to re-fetch to redraw. Long-running backend actions return 202 Accepted with a job resource and are processed outside the HTTP request handler. The job-driven set includes projection, model generation, model voxelisation and block-kit generation, Promo Studio photo and video generation, AI text assistance, text translation, Docusaurus publication, embedding refresh, notification dispatch, and future fulfilment-sync jobs. GET /jobs/{jobId} is the canonical Phase A progress interface; a job resource exposes public status, progress, current step label, the step list, the owning resource reference, the result reference, generated artefact references, configurable cost metadata, retry and cancel eligibility, safe error details, timestamps, and a recommended polling delay. Job creation is idempotent for user-retryable generation, translation, publication, and AI-assist operations; replaying the same idempotency key and request hash returns the existing job or completed result state rather than enqueueing duplicate provider calls or duplicate voxelisation work. Failed or cancelled jobs preserve the last successful draft, model, block-kit, Promo Studio scene or asset, or source-text state; retry creates or reuses a traceable job attempt and never overwrites newer source or draft state.
API responses include configuration-derived values for supported jurisdictions, the Phase A interest-reservation policy, the Phase A.5 supported Stripe card copy, AI generation costs, payout fees, payout thresholds, and the Phase A disabled-remix state. The application does not require hidden providers, hidden rollout stages, unsupported payment methods, or fixed non-configurable payout or generation numbers to complete any visible flow. User-visible product actions have typed API and domain contracts rather than opaque generic payloads; at minimum that applies to interest reservations, reservation cancellation, Phase A.5 saved carts, checkout delivery, payment, review, and confirmation, order notifications, order tracking, payment retry, delivery preferences, returns, replacements, reports, disputes, designer review replies, designer Q&A replies, designer message reports, designer claim actions, Help comments, projection, model, and block-kit job starts, Promo Studio job starts, and job retry-and-cancel controls.
The API exposes deterministic security and retry behaviour for beta traffic: public and private endpoint classification, authorisation failures, idempotency replay and conflict, CSRF failure, payload-size rejection, rate limiting, provider timeout and budget stop, and phase-blocked future actions all surface as typed responses rather than ambiguous errors. The backend rejects excessive search, upload, text, prompt, pagination, job-start, voxelisation, Promo Studio, large-language-model, and webhook requests before any expensive database, worker, or provider work is allocated. Public-safe /health, /livez, and /readyz endpoints let deployment, monitoring, and beta operations distinguish process liveness, traffic readiness, and sanitised dependency health. When a backend component, database, object store, worker, search index, Stripe, OAuth provider, AI provider, Docusaurus publication, email or support, or analytics integration becomes unavailable, the application-facing behaviour degrades only the affected capability, preserves user and domain state, and returns typed retry or unavailable states instead of accidental 500 errors. Critical state-changing operations fail closed when audit persistence, idempotency persistence, or required business-state persistence cannot complete; non-critical analytics and telemetry dispatch fails open and recovers asynchronously.
The backend accepts batched product-analytics events from the application through a typed endpoint; events use a controlled taxonomy, include session, device, surface, and context metadata, respect the consent class, and reject unknown event names or oversized properties before storage or forwarding. Founder and admin beta operations expose a dashboard API with activation, conversion, interest-reservation, Phase A.5 pre-order, listing-owner and designer, support, reliability, feedback, and product-learning metrics needed to decide whether the Phase A, Phase A.5, and Phase B gates are ready to open. Support operations include authenticated user-conversation creation, conversation listing and detail, user replies, staff queue listing, staff replies, assignment, priority, status changes, escalation flags, response service-level tracking, and links to related resource references. Beta feedback is accepted as a structured resource with the feedback type, rating or severity where applicable, the screen and surface context, related resource references, optional attachment references, the source language, translation state, and the moderation or support routing state. Reliability incidents and operational alerts are first-class operational records: founder and admin views expose current incidents, alert-rule state, last trigger time, owner, severity, impact, and a runbook or action summary. Technical logs, audit logs, analytics events, support content, and beta feedback are explicitly not one generic telemetry stream; each data class has its own retention, access, redaction, export, and deletion behaviour. Customer-behaviour instrumentation covers, at minimum, public discovery, search and filter, product detail, the create flow, upload and generation job start and completion, publish, interest-reservation create and cancel, Phase A.5 checkout and pre-order steps, authentication, dashboard, designer marketplace readiness, Help, support, beta feedback, and blocked or degraded states.