This page is the master software specification for the DomiDo platform. It is the umbrella that every other requirement in this section ties back to, stating what the platform is, what it must do, what it must not do, and how its capabilities are gated by the phased rollout. DomiDo is a universal application: today it ships as a Progressive Web App for the public beta, and the same React Native and Expo codebase is intended to run as iOS and Android applications later. The mock design files in the project repository are evidence of what the user interface should look like; they are not a substitute for the rules on this page. Where the mock conflicts with the policy decisions stated here, this specification wins.
The specification governs the entire visible application surface. On the customer side that means the public home page, the gallery of user-owned designs, the listing page, the creator and profile pages, the workshop and help content, the legal pages, the non-binding interest-reservation flow, and the future commerce surfaces that activate phase by phase. It also covers the authentication modals and every signed-in surface — the dashboard, account area, and settings — together with the design create flow from uploading a model and style references through projections, generated three-dimensional model, model feedback, the block kit, draft save, and publish. On the buyer side it covers interest reservations in Phase A, card-verification pre-orders in Phase A.5, captured orders in Phase B, and the fulfilment, receipt, delivery, return, replacement, dispute, support, and payment-retry flows that surround them. On the designer and listing-owner side it covers listing management, the Promo Studio media generator, projected commercial readiness, future royalties and entitlements, configurable Stripe Connect payouts, tax handling, messages, the disabled remix surfaces, and the action queue. The shared shell — footer, locale, currency, newsletter, cookies, privacy, search, supported-jurisdiction handling, social links, and the multilingual translation pipeline for user-generated content — sits across all of those domains.
A small number of platform-wide rules are non-negotiable and every other document inherits from them. Uploads to the create flow accept only GLB, GLTF, OBJ, and STL model files with a maximum size of one hundred megabytes; any other model or source format is rejected, and raster or reference media slots inside the create flow keep their own separate validation rules. Projections cover the six possible faces — front, back, right, left, top, and bottom — but only the front face is compulsory, and the other five are optional whether they come from the user, are generated automatically, or are left blank. Every artificial-intelligence generation cost (projection generation, three-dimensional model generation, block-kit generation, and Promo Studio photo and video generation) is returned by the backend rather than hard-coded into requirements, API schemas, or the user interface. The create wizard always opens onto a saved draft or saved generation state where one exists; starting a fresh blank draft is a deliberate second-step choice. The three-dimensional model generation pipeline must collect user feedback on the quality of every generated model, and the backend stores that feedback for pipeline analysis and correction.
Stripe is the sole payment provider — the platform does not define and must not expose any non-Stripe payment option — and accepted-card copy is derived from the card types Stripe supports in the buyer's jurisdiction rather than a universal list baked into the requirements. The list of supported buyer jurisdictions is configurable, and unsupported jurisdictions show a clear coming-soon notification. The Value-Added Tax shown at the checkout review step is calculated for the buyer's specific jurisdiction. Physical-kit demand is represented by three distinct record types, one for each phase, and the same code path must never blur the lines between them: a Phase A interest reservation is non-binding — no card step, no charge, no order, no invoice, no shipment, no pre-order, no ship-date promise — and just records that the user is interested; a Phase A.5 pre-order is invited-only, uses a Stripe SetupIntent with no capture to verify the card without taking money, and requires fresh buyer consent plus listing-owner terms, moderation, intellectual-property, regulatory, product, pricing, and support gates all to clear before it can be raised; a Phase B order is a captured purchase via Stripe PaymentIntent, created only when Phase B gates pass and an eligible pre-order is converted.
The order pipeline supports return-fee assessment when returned blocks are damaged, show wear, are returned for change of mind, or have diminished value, and the trust pipeline may blacklist or restrict a user for anti-abuse reasons, including customer extremism — any such decision must be visible to support and dispute handlers and must be challengeable by the affected user through a support ticket or a dispute. Users and designers own the aesthetic designs they create and the listing content they author, subject to third-party rights and platform rules; the platform receives only the limited licence needed to host, process, translate, moderate, display, validate, and eventually manufacture eligible designs after explicit terms are accepted, and it must never present user-created designs as platform-owned or platform-authored.
Designer and listing-owner monetisation becomes available in Phase A.5, before Phase B fulfilment. Phase A.5 may activate owner terms, public profile readiness, listing qualification, attributed demand from SetupIntent pre-orders, projected entitlements, Stripe Connect and Know-Your-Customer preparation, payout settings, statement previews, and reserve and dispute modelling; real cash payout requires captured customer funds and payout eligibility, which arrive only after Phase B delivery, and no designer cash payout is released from Phase A interest reservations or Phase A.5 SetupIntent-only pre-orders. Every payout threshold, fee, schedule, eligibility delay, and payout label is configurable — the specification does not encode a per-block royalty amount, fixed monthly payout dates, or fixed reversal windows as product truth. Remixes (derivative designs by third parties) are disabled in Phase A, and Phase A.5 may prepare the marketplace controls but remix split proposals stay non-cash-impacting until a later approved expansion enables active remix economics.
The Workshop and Help sections use Docusaurus as the static-site generator for published knowledge content. The specification defines the information architecture, search, article reader, support, and administration structure, but never the actual article bodies, slugs, shipping windows, material claims, application statistics, or story details. Only administrators may create, update, publish, unpublish, archive, or delete Workshop and Help content, and a Docusaurus build or static export is a published projection of approved content rather than an independent source of truth.
The platform is multilingual at the data layer, not just at the chrome. Every free-form user-generated text field is stored with its source language, the original text, the field and resource context, author and audience context, translation status, and generated translations for every backend-configured supported language; translation runs asynchronously on save through a backend large-language-model adapter, and the source text is saved immediately and remains the fallback until translated variants are ready. The translation pipeline applies only to user-generated free text — design prompts and briefs, draft publish copy, listing titles, descriptions and tags, designer biographies, reviews, questions and replies, messages, help comments, support conversations, report and dispute notes, Promo Studio prompts, and similar authored content — and it must never translate structured or sensitive fields such as names, emails, phone numbers, addresses, payment data, file names, identifiers, Value-Added Tax and tax fields, OAuth profile data, or credentials. Supported languages, the default language, the fallback order, translation provider availability, and the on-or-off state of the translation feature are all backend configuration; English, German, French, and Dutch are seed examples, not the only supported languages.
Mock copy is evidence only. Language labels, locale and currency pairs, jurisdictions, delivery methods, search scopes, moderation-rerun costs, ad-boost budgets, and any other values shown in the mock are display examples whose real values come from backend configuration at runtime — mock copy naming fixed Value-Added Tax rates, carriers, delivery estimates, refund timing, attachment limits, report categories, policy snippets, or delivery promises is user-interface evidence only and is replaced with typed domain data before the screen is shown. When a mock surface mixes a valid workflow with the wrong delivery phase, the surface is decomposed: the user-interface workflow stays in scope, but the inactive behaviour is blocked, made read-only, marked coming-soon, waitlisted, or deferred. This applies in particular to checkout confirmation, payment retry, saved carts, buyer order sheets, designer earnings, Stripe Connect, payout transfers, reserves and disputes, shipments, returns, and the build companion; Phase A public listing actions reserve interest — they do not collect payment and do not create pre-orders.
Audit logs, technical logs, analytics events, support content, and beta feedback are separate data classes with different retention, access, redaction, export, and deletion rules, and they are never collapsed into one generic telemetry stream. Before open beta, the platform provides administrator-facing support operations — searchable conversations, staff replies, status changes, escalation flags, and response-time tracking — together with a founder beta dashboard backed by backend APIs rather than manually maintained spreadsheets, and it collects structured beta feedback from users and testers, translates and localises it where needed, and connects it to the relevant screen, order, model, support conversation, or experiment. The platform also defines and persists a controlled product-event taxonomy for customer behaviour, conversion, reliability, support, and beta-learning events.
Every major capability carries a delivery state: Phase A active (required for the first public-interest Web and Progressive Web App beta), Phase A conditional (active only if specific launch gates are met, otherwise blocked or replaced by free or manual beta behaviour), Phase A.5 active (required for the gated conversion of selected interest reservations into no-capture pre-orders and for supply-side readiness before real order fulfilment), Phase B active (required when real order capture, manufacturing, third-party logistics, shipment, delivery, returns, and the build companion become active), Phase C expansion (advanced marketplace expansion after Phase A.5 and Phase B readiness), Native deferred (the native iOS, Android, App Store, and Play Store release rail — not a Web/PWA beta requirement, but the universal app architecture must remain compatible), and Blocked, read-only (a surface may be visible but disabled, read-only, waitlisted, or coming-soon until its phase is active).
Phase A is the public interest beta. It includes public discovery, the user-owned gallery, the create flow in both Mode A (describe in words) and Mode B (upload a three-dimensional model), listing publishing, non-binding interest reservations, the user dashboard reservation state, the founder and admin beta dashboard, analytics, support, moderation and reporting, and legal and trust copy. It excludes cards, charges, pre-orders, orders, invoices, shipment promises, designer payouts, and any platform ownership claims over user designs. Phase A.5 is the gated pre-order and supply activation phase that must clear before Phase B can open: it activates selected reservation conversion invites, fresh buyer consent, listing-owner terms, public profile and readiness, listing qualification, Promo Studio readiness where needed, marketplace discovery refinement, Stripe SetupIntent no-capture pre-orders, projected entitlement and readiness views, Stripe Connect and Know-Your-Customer preparation, statement previews, reserve and dispute modelling, and payout readiness, with heavy review, question-and-answer, and message workflows active only when needed to acquire and qualify enough supply before real fulfilment. Phase B activates only after Phase A and Phase A.5 readiness gates pass, and includes card capture via PaymentIntent, manufacturing and third-party logistics, shipment, delivery, receipt and invoice, returns, replacements, disputes, the build companion for delivered kits, and actual payout release when delivery-based eligibility is met.
The native iOS and Android release rails, App Store and Play Store submission, and Apple and Google billing requirements are deferred from the Web/PWA beta; they remain evidence for later surface-specific launch gates, and the production application architecture must stay React Native and Expo compatible. The current mandatory validation target is Web and Progressive Web App on desktop, plus mobile-width browser smoke tests; iOS and Android behaviour is a compatibility requirement and a later gate, not a mandatory Phase A acceptance target.
DomiDo runs as a React Native and Expo universal application with a Web/PWA beta surface for public browsing, signed-in account areas, creator and listing-owner tools, interest reservations, and future commerce surfaces. The modal and sheet patterns from the mock are all supported — authentication modal, navigation drawer, search modal, cart drawer, support and help sheets, payment retry, order action sheets, and account forms — and the platform supports direct navigation to every visible public and signed-in surface, with no hidden onboarding steps required. Enough server-side state is persisted to resume create drafts, generation outputs, Promo Studio scenes and assets, saved listings, interest reservations, Phase A.5 checkout drafts and progress, saved addresses, saved Stripe payment references, Phase A.5 pre-order commitments, Phase B order records, reservation, pre-order and order notification read state, listing-owner and designer listings, designer payout settings, help discussion records, and support conversations across sessions.
The platform exposes a REST API and an OpenAPI contract; API fields use product domain concepts and never expose implementation storage or queue products. Long-running work — create flow steps, Promo Studio generation, AI assistance, translation, publication, and future fulfilment — runs as backend jobs. HTTP handlers create or reuse idempotent jobs and return quickly, while workers perform the heavy model generation, voxelisation, blockification, external AI calls, and publication. Job resources expose polling progress, the current step, the full step list, result and artefact references, configurable cost and configuration references, safe error details, retry and cancel eligibility, timestamps, and source-stale protection.
The translation pipeline runs on the same job machinery. Mutations on translatable user-generated text trigger asynchronous translation jobs, and read responses resolve display text using the explicit request language where present, the user's preferred content language, the Accept-Language header, the configured fallback order, and finally the source text. Editor, admin, support, and dashboard surfaces expose translation status and stale or missing language indicators where useful. Phase A Web/PWA desktop testing includes product-event ingestion, founder-dashboard visibility, the user-to-staff support reply flow, beta-feedback capture, alert smoke evidence, and log redaction and correlation evidence for the critical happy path.
The home surface includes upload entry, inspiration and gallery entry, creator entry, newsletter entry, and gallery rail content. The public create-upload entry communicates the supported model formats (GLB, GLTF, OBJ, STL) and the one-hundred-megabyte size limit. The gallery supports browsing live listings and exposes the filtering and search metadata required by the gallery cards and listing pages. Listing pages expose product imagery and media, owner and creator attribution, save, share and report actions, kit and assembly details where available, the interest-reservation call-to-action state in Phase A, the Phase A.5 pre-order call-to-action only when invited and eligible, reviews and questions where active, delivery and jurisdictional Value-Added-Tax copy only where phase-appropriate, and alternate product-detail commerce panels as distinct mock surfaces. Creator and designer profile pages expose profile identity, owned public listings, follows, portfolio, and creator-specific social and contact affordances, but only when active for the current phase; Phase A may show lightweight owner attribution and profile data without activating marketplace monetisation. Workshop, help, and legal surfaces expose a Docusaurus-generated published help and workshop site with a general help hub, topic navigation, article reader, search, related content, cookie controls, privacy and legal links, sitemap, and data-request links. Runtime widgets or adjacent application surfaces provide article discussion and comments where enabled, plus support entry points; specific article body claims and seeded comment text are content data, not requirements.
The create flow preserves five stages: Describe, Projections, Three-dimensional model, Block kit, and Save and publish. The Describe stage collects title and brief, supported model and source media, media validation state, reference text, category and tags, and the draft metadata needed by later stages; it supports configurable style reference presets that can add style descriptors to the prompt and set a reference image, and presets are data-driven and may include display label, palette description, descriptor text, seed prompt, swatch colours, and thumbnail or reference media. The wizard entry loads the user's latest saved draft or saved generation state when one exists and provides a clear way to continue or start a new draft. The Projections stage manages six face slots, with only the front face required, and the optional faces support source attribution, generated preview media, active-face state, history entries, restore and reuse actions, zoom state, and optional autofill. The Three-dimensional model stage manages generation options, configurable generation costs, progress, the tryout history, output statistics, source reuse, the selected tryout, and GLB or GLTF-compatible result references, and it collects user feedback for each generated model tryout including quality assessment, selected issue categories, optional comments, and whether the model was usable. The Block kit stage manages configurable generation cost, generation status, bill-of-materials groups, Stock-Keeping-Unit and part counts, estimated build time, estimated cost, assembly steps, and the payloads used by buyer and listing surfaces. The Save and publish stage manages listing visibility, ownership and licence acknowledgement, the intended-use and safety gate, the disabled Phase A remix notification, optional future royalty and entitlement controls where phase-active, draft save, and the publish action; Phase A publishing does not require monetisation or payout setup.
In Phase A, buyer demand uses non-binding interest-reservation surfaces rather than cart and payment checkout, and cart and checkout surfaces may remain blocked, hidden, read-only, or waitlisted until Phase A.5 or Phase B opens. In Phase A.5, invited eligible reservations may use the Bag, Review, Payment, and Confirmation surfaces to create a Stripe SetupIntent no-capture pre-order, and in Phase B, checkout and capture create a charged order. Delivery supports saved addresses, manual address entry, supported-jurisdiction validation, delivery-method selection, collection-point selection where available, and a delivery summary with pricing. Payment is absent from Phase A interest reservations; the Phase A.5 and Phase B payment surfaces support saved Stripe card references, Stripe-hosted or Stripe-mediated new-card verification or capture according to phase, Stripe payment or SetupIntent status, promo and discount entry where visible, and accepted-card copy based on Stripe support in the user's jurisdiction. Checkout review shows jurisdiction-dependent Value-Added Tax where applicable, delivery or future-delivery assumptions, item totals, expected final total, Stripe verification or payment status, an explicit Phase A.5 no-capture acknowledgement when applicable, and any unsupported-jurisdiction message; it does not show a post-checkout wait-time metric or a promised ship date.
Phase A confirmation creates an interest reservation with non-binding acknowledgement, cancellation eligibility, listing and owner reference, indicative price or price-unavailable snapshot, and dashboard visibility. Phase A.5 confirmation creates a no-capture pre-order with SetupIntent or card-verification state, gate versions, cancellation eligibility, no-capture acknowledgement, expected kit price, and dashboard visibility. Phase B order creation routes to one of three fulfilment states — ready to ship immediately, waiting for required blocks, or waiting for production readiness — with email notification when ready to ship. Buyer dashboard management supports Phase A interest reservation details, reservation cancellation, support contact and messages, and trust and blacklist dispute visibility where applicable; Phase A.5 adds no-capture pre-order details, pre-order cancellation, and SetupIntent and card-verification state; Phase B order management adds shipment and parcel tracking, estimated-time-of-arrival and change labels, payment retry through Stripe, address change, delivery preferences, receipt and invoice, returns, replacements, issue reports, and disputes, with each action using a typed payload, eligibility state, validation messages, attachments where enabled, result status, and an audit-ready timeline event. Saved cart and checkout draft management supports listing saved carts, resuming a saved cart into checkout, discarding a saved cart, showing stale or unavailable item validation, and preserving the jurisdiction, delivery, and Value-Added-Tax configuration used for the draft. Buyer order update inboxes support notification item lists, unread and read state, severity, linked order and action targets, mark-read, and mark-all-read behaviour. Buyer order management supports the build companion at a general capability level: Quick-Response-code or open-from-order entry, step payloads, progress saving, support escalation, finished-build photos, profile sharing, designer feedback permission, and a separate build-experience rating.
Listing-owner and designer tools support the title, description, category, tags, media, assembly, visibility, and listing status operations visible in the mock; price, royalty, projected entitlement, Stripe Connect, and payout controls are blocked or read-only until their active phase. Designer listing tools show Phase A remix controls as disabled where present and explain that remixes are not available in Phase A. Designer dashboards expose sales, earnings, payout status, statement export, fee displays, message and action queues, disabled-remix action states where applicable, boost spend where present, and listing performance. Designer listing editor aggregates expose owner edit state, unsaved and versioned save state, editable versus platform-owned sections, moderation flags and visibility restrictions, similarity and uniqueness matches, section and listing analytics, action items, and the configured cost and eligibility for any moderation rerun.
In Phase A.5, payout settings support Stripe Connect connection state, identity and Know-Your-Customer state, configurable payout options, payout schedule state, pause and resume of automatic payouts where available, payout on request with a configurable fee defaulting to two percent, below-minimum payout handling with a configurable fee defaulting to two percent, tax region, Value-Added-Tax number, Unique Taxpayer Reference, and a clear separation of fields held by Stripe versus fields held by the platform. These settings establish payout readiness before fulfilment; cash transfer release remains Phase B delivery-dependent. Future royalty and entitlement rules support listing markup values inclusive of Value-Added Tax where applicable, Phase A.5 projected entitlements from attributed SetupIntent pre-orders, payout eligibility no earlier than thirty days after Phase B delivery, configurable payout numbers, return and diminished-value adjustments, dispute and reserve adjustments, payout bundle traceability, and statement and export traceability; Phase A interest reservations do not accrue payable royalties.
The Promo Studio allows a listing owner to generate promotional listing media from an owned listing's model and media. It includes scene staging, generated photos, generated videos, and an asset library, and generated Promo Studio media remains private until the listing owner explicitly adds it to listing media or downloads it through an authorised action. Scene staging supports configured environment presets, optional custom High-Dynamic-Range-Image or reference-environment upload, lens presets, object position, scale, rotation and yaw, camera pan, tilt, crane and dolly-style state, reset, source-render preview, and source-model footprint metadata. Photo generation uses the current scene, a prompt, a selected style preset, and the configured generation cost, with results supporting keep and star, animate-from-photo, download, add-to-listing, generation history, and failure and retry state. Video generation requires a generated photo as the first frame, then supports source-photo selection, motion prompt, configured duration and aspect options, play and pause preview state, keep and star, download, add-to-listing, generation history, and failure and retry state. The library supports All, Photos, Video, and Starred filters, counts, empty states, download-all where authorised, per-asset download, per-asset listing-gallery publication state, and removal or archive where implemented.
Sales and payout surfaces support attributed interest demand in Phase A, attributed no-capture pre-order demand in Phase A.5, disputed sale status where applicable, sale lifecycle milestones, payout readiness, payout transfers after Phase B eligibility, failed payout resolution, reserve holds and releases, payout activity events, tax statement exports, and new and unconnected Stripe states. Demonstration amounts, dates, grace periods, reserve percentages, provider dispute fees, and provider tool names shown by the mock do not become product requirements unless supplied by backend configuration. Designer listing engagement supports owned-listing review-reply workflows, question-reply workflows, add-to-FAQ candidate creation, designer message threads, message reports, and claim and dispute action handling; these workflows preserve draft, reply, update, and delete state where allowed, internal-note state where visible, moderation and report status, linked listing, order, or claim references, and user-visible resolution history.
Account settings support profile, addresses, saved Stripe payment references, orders, notifications, privacy, security, and designer payout and tax settings according to the dashboard surfaces. Locale and currency selection match the configured application options, and supported buyer jurisdictions are configuration-driven and produce a coming-soon notification when unsupported. Locale selection affects the user-interface chrome and the preferred language for translatable user-generated content responses; changing locale does not rewrite source user inputs, but future writes may use the new locale as the default source language when the user does not provide one. Cookie, privacy, terms, accessibility, sitemap, and data-request links are available from the footer and legal surfaces, and cookie preferences are persisted and revocable. Notification preferences support categories visible in the account and dashboard surfaces — including order, designer, payout, message, production readiness, jurisdiction availability, and marketing-style notifications where visible — and account notification items are distinct from notification preferences in that they capture concrete events with read or unread state, severity, source surface, linked resource or action target, and mark-read or mark-all-read behaviour. Trust restrictions, including blacklist state applied for anti-abuse or customer-extremism reasons, are shown only to authorised roles and support support-ticket or dispute challenge. Account lifecycle and security surfaces support profile and avatar updates, password and session controls where applicable, two-factor state where applicable, data-export request and status, pause account or shop request, and delete-account request and status as visible in the mock.
Prototype helper files (design canvas, tweak panels, iOS frame wrappers) do not create production requirements unless a user-facing behaviour is also visible in active screens or explicitly required above. The specification does not claim a production database, object store, worker system, deployment provider, observability provider, email provider beyond user-facing email notifications, or analytics provider; Docusaurus is the explicit exception because it is a product-delivery decision for public knowledge content, not a persistence or infrastructure provider. The specification does not claim hidden rollout dates, fixed payout dates, fixed payout thresholds, fixed AI generation costs, fixed moderation or advertising costs, fixed locale, currency, or jurisdiction lists, unsupported payment methods, Phase A pre-order or no-charge checkout semantics, unphased commerce semantics, or fixed review wait times. Stripe is the only payment provider, and any non-Stripe payment-method copy from the mock files is superseded and is not implemented.