This page converts the platform requirements into implementation guidance for the engineering team. The mock is static React, JSX, and CSS evidence; the production target is React Native and Expo with React Native Web for Web/PWA, and the same codebase is intended to package as iOS and Android later through platform adapters. Backend, hosting, storage, queue, and observability product choices not proven by other requirements are out of scope here — those are an architecture decision the team makes after the requirements are approved. Delivery phase gates govern which visible surfaces are active, preview-only, or blocked, so the engineering brief below is consistent with the Phase A, Phase A.5, and Phase B framing used everywhere else in the requirements section. Throughout the page, the principle is that the universal app target, the typed domain contracts, and the configurable product knobs come first, and product-domain code never reaches for browser-only or vendor-specific dependencies outside the adapter layer.
The implementation separates public browsing, create tooling, Promo Studio, buyer commerce, designer commerce, account settings, and support and legal surfaces into maintainable frontend modules, and it targets one React Native and Expo application rendered through React Native Web for Web/PWA and packaged later for iOS and Android. Web desktop is the current mandatory validation target; the other platforms are compatibility gates whose layout intent is preserved without being acceptance gates yet. The frontend uses typed API and domain models equivalent to the logical data requirements. Type names may differ, but the fields required by the mock are not dropped, and the user-visible interest reservations, saved carts, checkout steps, Phase A.5 pre-orders, order notifications, tracking, order actions, designer review, Q&A, message, and claim workflows, and Help comments are not implemented as untyped generic blobs.
API request code centralises the cross-cutting concerns: authentication, locale, currency, and Accept-Language headers, source-language hints for text mutations, error normalisation, retry policy for idempotent reads, and validation-message handling. Long-running projection, model generation, block-kit and voxelisation, Promo Studio photo and video, AI text assistance, text translation, publication, embedding refresh, notification dispatch, and future fulfilment-sync work use the shared job resources rather than ad-hoc patterns. Phase A uses polling through GET /jobs/{jobId} with pollAfterMs; server-sent events or WebSocket transport is not required. Media upload code supports the accepted raster and reference formats where applicable and supports only GLB, GLTF, OBJ, and STL for model and source uploads up to 100 megabytes — the validation is the same in the UI, the API, and the worker boundary.
UI state preserves multi-step form progress across the create, Promo Studio, Phase A interest, and checkout flows, including partially completed forms, saved draft and generation state, Promo Studio scene and assets, selected tabs, active projection face, selected model tryout, interest-reservation acknowledgement state, saved cart and checkout draft state where Phase A.5 or Phase B is active, selected delivery method, selected Stripe payment reference, and selected publish settings. The product decisions that override mock copy — Phase A non-binding interest reservations with no card or payment step, Phase A.5 invited SetupIntent no-capture pre-orders and designer marketplace and payout readiness, Phase B payment capture, fulfilment, and payout release, supported jurisdictions, configurable AI costs, configurable Promo Studio costs and options, configurable payouts, reserves, and disputes, and Phase A disabled remixes — are represented through configuration and data rather than hard-coded UI assumptions. Multilingual user-generated content is represented through backend LocalizedText and LocalizedFieldMap data and asynchronous textTranslation jobs; the frontend does not call LLM translation providers directly.
The application implements the Web desktop layout as the current mandatory beta target and preserves mobile, tablet, and native layout compatibility as a future gate. Responsive and mobile behaviour from the mock guides architecture and component shape but does not block Phase A acceptance. The reusable component vocabulary — headers, footers, modals, drawers, sheets, cards, tabs, segmented controls, sliders, steppers, upload slots, and table or list patterns — is shared and consistent across surfaces, so that the same component does not exist in three slightly different shapes across the app.
Module boundaries are deliberate. Create-stage components are split so projection-face logic, model tryout logic, block-kit and BOM logic, and publish settings can be tested independently; Create Describe style presets are loaded through configuration and domain data and applied through a testable prompt and reference-media update path. Buyer commerce components isolate the Phase A interest reservation call-to-action, acknowledgement, and cancellation, and separately isolate the Phase A.5 and Phase B Bag, Delivery, Payment, Review, Confirmation, saved-cart resume and discard, SetupIntent verification, Phase B capture readiness, and validation state while sharing typed reservation and checkout resources. Designer dashboard components isolate listing management, Promo Studio launch state, Phase A attributed interest reservations, Phase A.5 attributed no-capture pre-orders, projected royalties, payout readiness, payout and tax settings, payout transfer ledger, reserve ledger, dispute details, review replies, Q&A replies, message threads, claim actions, action queue, statement exports and previews, messages, ad boost, and the Phase A disabled-remix states. The listing editor isolates owner edit state, editable and platform-owned sections, moderation flags and rerun state, similarity matches, listing analytics, action queue context, the unsaved-leave guard, and the buyer preview. Promo Studio components isolate the wizard shell, scene staging, photo controls and results, video controls and results, and library actions so generation jobs and listing-gallery publication can be tested independently. Account settings use consistent form handling for profile, address, payment reference, privacy, notification, security, and payout-and-tax forms.
The UI does not display providers, currencies, countries, model formats, delivery methods, payout schedules, or OAuth options that are absent from the requirements. Every visible asynchronous action exposes loading, success, validation error, and general failure states. Accessibility — keyboard operation, focus, and labels — covers the header navigation, modals, drawers, tabs, sliders, form fields, and action menus. Platform-sensitive behaviour is isolated behind adapters for navigation and linking, local storage, safe areas, media selection and upload, Stripe payment handoff, file download and export, browser-only APIs, and native-only APIs, so production UI modules do not reach for the DOM, CSS-only behaviour, browser globals, or build-tool-specific dependencies outside the web adapters or transitional mock-derived evidence. Free-text entry components that create public, shared, support, or designer-facing content send the entered source text plus a source-language hint where known. Owner and admin surfaces render translation pending, failed, and stale state where the API exposes it. Public surfaces render backend-resolved text and fallback state without claiming fallback is a completed translation.
The REST API implements the paths defined in the interface requirements and the OpenAPI specification. REST responses return complete UI-ready resource snapshots after mutations, so the frontend does not have to infer derived state from unrelated calls when a surface updates. Validation errors come back with field paths, machine-readable codes, and user-facing messages suitable for inline display, and the rate-limit, idempotency, CSRF, webhook-signature, and bounded-request decisions are all represented as typed contracts rather than as undocumented middleware behaviour.
Mutating endpoints support idempotency for the long list of operations that can be retried by a flaky network: interest reservation create, cancel, and conversion-invite, checkout, Stripe SetupIntent, session, and payment reference creation, Phase A.5 pre-order commitment and cancellation, order actions, return assessments, generation job creation, translation job creation, Promo Studio job creation, Promo Studio asset publication, model feedback, payout readiness changes, payout release requests, payout retries, trust challenges, help-content admin actions, and publish actions. APIs accept and return configuration metadata for jurisdiction support, Stripe-supported card copy, delivery phase gates, AI generation costs, multilingual translation languages, fallbacks and provider state, Promo Studio presets, options and costs, payout fees, thresholds and schedules, reserve and dispute rules, disabled-remix state, and alternative surface variants. The API design avoids leaking storage paths, queue names, secret values, raw card data, or provider account internals.
The API implementation rejects untyped generic payloads for the user-visible mutations that the requirements call out by name: interest reservation endpoints, saved carts, checkout step mutations, Phase A.5 pre-order endpoints, order notification state, order tracking and action endpoints, designer engagement endpoints, and Help discussion endpoints. These endpoints use named schemas, field-level validation, and resource snapshots aligned with OpenAPI. APIs that read translatable content resolve display strings by explicit API language, the user's preferred content language, the Accept-Language header, the configured default language, and then source text; APIs that mutate translatable content persist source text first and queue async translation without blocking the source mutation.
Upload handling validates file format and size before creating create-draft media, with model and source files limited to GLB, GLTF, OBJ, and STL, and 100 megabytes. Raster uploads preserve original metadata alongside normalised WebP output metadata. Projection generation is resumable by draft and face, with history restore and source reuse. Model generation supports configured option selection, progress, retry, the selected tryout, a GLB and GLTF-compatible result, stats display, and user quality feedback capture. Block-kit generation supports configurable cost display, job progress, model validation, voxelisation, blockification, BOM groups, search and filter, assembly steps, SKU count, part count, build time, cost summary, retry, cancellation where safe, and stale-result protection. Generated media references carry stable IDs and user-facing preview URLs, and the storage implementation is intentionally unspecified at the requirements layer.
Promo Studio generation persists scene snapshots, source listing, model, and media references, prompts, style and motion settings, source photo references, configured cost version, generated asset references, keep-and-star state, download state, and listing-gallery publication state. Private assets do not appear in public listing payloads until the add-to-listing operation marks them as listing media.
Phase A interest reservation state survives page navigation and sign-in changes, and Phase A.5 and Phase B cart and checkout state survives the same transitions where those gates are active. Phase A interest reservations reserve enough data to show listing and owner attribution, non-binding acknowledgement, cancellation state, supported-jurisdiction or non-convertible state, and later conversion-invite eligibility; Phase A.5 and Phase B checkout reserves enough data to show jurisdictional VAT, supported-jurisdiction state, SetupIntent and payment readiness, no-capture acknowledgement, and fulfilment readiness after Phase B order confirmation.
Stripe checkout, card verification, and capture are implemented so the platform stores only masked Stripe payment references and verification or status metadata. Phase A does not create Stripe objects for interest reservations; Phase A.5 uses SetupIntent-style no-capture verification for invited physical-kit pre-orders; Phase B uses Stripe payment capture for orders. The implementation does not expose non-Stripe payment options, and the accepted-card copy comes from Stripe support in the user's jurisdiction rather than from a hard-coded list baked into the application. Interest reservation, pre-order, and order actions are modelled as explicit state transitions for reservation create, cancel, and conversion invite, pre-order verification, cancellation, and conversion readiness, payment retry, cancellation, address change, delivery preference, returns, return-fee assessment, replacements, disputes, refunds, trust-restriction challenges, and support. Receipt and invoice exports use Phase B order data that includes VAT, refund, charge, and masked payment reference fields — Phase A interest reservations and Phase A.5 no-capture pre-orders do not expose receipt or invoice exports.
The buyer dashboard supports interest reservation status, cancellation, and conversion-invite state, Phase A.5 pre-order status, cancellation, and conversion readiness, order notification read state, saved cart resume and discard, typed shipment tracking detail, typed delivery preferences, and typed order action sheets without hard-coding carrier, ETA, VAT, refund timing, attachment limit, or report category demo values.
Royalty percent uses a shared validator enforcing the 0–25 range. Listed price is derived consistently from base kit price and royalty percent where the listing designer mock shows that relationship. Ad-boost budget uses a shared validator enforcing backend-configured bounds, and the mock budget values are display examples rather than hard-coded truths. Designer payout settings separate fields held by Stripe from fields held by the platform and reflect that separation in UI copy and data contracts. Phase A.5 implements payout readiness without releasing money before Phase B eligibility. Payout options, payout schedule, auto-payout pause state, payout request fee, below-minimum payout fee, minimum payout, tax region, VAT, UTR, statement preview and export, and transaction-record retention copy are implemented from configurable payout settings rather than from baked-in values. Remix split proposals are disabled in Phase A and do not create active payout effects.
Designer payout engineering supports Phase A attributed interest reservations, Phase A.5 attributed no-capture pre-orders, projected royalties and entitlements, payout readiness, and statement previews, and Phase B available, pending, in-transit, and reserved balances, payout transfers, failed payout retry and remediation, reserve ledger, sale lifecycle, dispute detail, payout activity events, and tax statement export — all without hard-coding demo payout dates, grace windows, provider fees, or reserve percentages. Engagement engineering supports typed review replies, question replies, FAQ candidates, message thread replies and reports, and claim actions with ownership checks, moderation and report state, and linked listing, order, support, and dispute references.
Requirement verification includes REST and OpenAPI path parity checks against the interface specification. Current required app verification runs against Web desktop; Web mobile, iOS, and Android checks become mandatory only when their phase gates open, though production code remains compatible by using shared React Native primitives and platform adapters. Requirement verification also includes a banned-claim scan for unsupported payment options, obsolete upload limits, unphased pre-order or no-charge claims, Phase A direct-charge claims, fixed AI costs, fixed Promo Studio generation costs, fixed checkout or order demo values, fixed payout schedules, fixed reserve or dispute demo values, and unsupported model formats.
Frontend tests cover the full create-flow surface area — saved draft resume, create style preset application, compulsory front projection, optional face handling, projection history restore, job polling, retry, and cancel states, model option selection, model feedback, block-kit voxelisation progress, block-kit BOM filtering, publish settings — and they cover multilingual source-text fallback and translation status, Promo Studio stage, photo, video, and library flows including download-all, saved cart resume and discard, Stripe SetupIntent pre-order review and confirmation state, Phase B Stripe checkout review state, unsupported-jurisdiction handling, pre-order cancellation and conversion readiness, order notification read state, order tracking detail, order action sheets, return fee assessment, designer review, Q&A, message, and claim workflows, designer listing editor moderation, similarity, and analytics state, designer payout readiness and settings, payout transfer, reserve, and dispute states, configured ad-boost validation, Help comments, account lifecycle and security flows, and disabled-remix actions. API tests cover all enum restrictions defined in the data requirements and the validation messages required by the functional requirements. Accessibility tests cover keyboard and focus behaviour for the authentication modal, enabled navigation surfaces, search modal, cart drawer, create tabs, checkout steps, designer forms, and account settings on the current Web desktop target.
The platform does not mandate a deployment provider, hosting topology, database, cache, queue, object store, metrics product, logging vendor, or secret-management product. Production operations still provide secure configuration, backups for persistent business data, monitoring of user-visible failures, and alerting on checkout, pre-order, generation, payout-readiness and release, and order-action failures — those obligations live in the non-functional requirements and are not weakened here. The product and tool choices that satisfy them are defined in a separate architecture decision after the requirements are approved.
Environment variables and secrets are limited to the providers actually used by the implementation. The named external providers are Stripe, Google, Apple, and Facebook. LLM translation uses a provider-neutral adapter and does not make any specific LLM vendor normative. Engineering documentation does not reintroduce unproven providers or infrastructure as normative requirements.