DomiDo is a marketplace for universal building blocks and the user-generated designs that snap together from them. The business rules collected on this page describe how the platform behaves commercially: when money may be touched, how interest becomes a pre-order and a pre-order becomes a captured order, what royalties and payouts a designer can expect, how returns and disputes are resolved, how listings and Promo Studio assets travel from private drafts to public media, and how editorial content on Workshop and Help is governed separately from user-generated discussion. Every rule on this page is policy that the software must honour. Mock copy that contradicts a rule is not a rule, and copy that activates a future phase before its gates open is not a rule either. The rules are deliberately phase-aware because DomiDo is shipped through a staged opening — Phase A for non-binding interest, Phase A.5 for invited no-capture pre-orders and designer marketplace readiness, and Phase B for real fulfilment and payout release — and almost every commercial behaviour on the platform depends on which of those phases is currently active.
The delivery phase state is the single switch that controls which commercial features are alive at any moment. Valid states are phaseAActive, phaseAConditional, phaseA5Active, phaseBActive, phaseCExpansion, nativeDeferred, and blockedReadOnly, and each surface in the application gates its behaviour on that state rather than on copy or feature flags scattered through the codebase. Phase A is the public interest beta: it creates non-binding physical-kit interest reservations and nothing else. During Phase A the platform does not collect cards, does not create Stripe customers or payment objects, does not create legal pre-orders, does not capture physical-kit funds, does not raise receipts or invoices, does not start shipments, does not release designer payouts, and does not promise a ship date for anything. Phase A.5 opens selected reservation conversion and the designer marketplace surface before real order fulfilment begins; it carries fresh buyer consent for an invited pre-order, Stripe SetupIntent no-capture verification, designer and listing-owner terms, listing management, Promo Studio, Stripe Connect onboarding and Know-Your-Customer collection, projected entitlement accounting, payout configuration, statement previews, reserve and dispute modelling, and payout readiness. Phase B activates real order fulfilment only after both the Phase A and the Phase A.5 readiness gates have been satisfied, and it is the only phase in which capture, fulfilment, shipment, delivery, returns, and actual payout release take place.
A DomiDo user signs in only through Google, Apple, or Facebook OAuth; no other identity provider is offered, and a single signed-in account can carry buyer, designer, and admin-content capabilities concurrently where authorisation permits. Header language options, supported content languages, the default language, the fallback order, and any locale or currency choices presented to the user are configuration values exposed to the frontend and backend workers rather than hard-coded product truth, which means mock language and currency labels in the design surfaces are examples and not commitments. The platform never quietly introduces a currency outside its configured product support.
Free-form user-generated text — descriptions, comments, reviews, messages, questions, FAQ candidates, support text, and similar fields — is stored in the source language as the user submitted it and translated asynchronously into the configured supported languages, so saving the source never waits for translation to finish. Structured and sensitive fields are excluded from the LLM translation provider entirely: names, email addresses, phone numbers, postal addresses, payment data, security data, file names, identifiers, VAT and tax fields, OAuth profile data, and credentials all stay off the translation path. When a requested translation is unavailable, has failed, or is stale relative to the source, the display falls back through the configured fallback order and finally to the source text rather than showing an empty field.
Supported buyer jurisdictions are maintained as a configurable list, and that list governs more than just where the platform will sell. Jurisdiction drives interest-conversion eligibility, Value-Added Tax calculation, delivery availability, the accepted-card copy a buyer sees at checkout, and any checkout-blocking rule that applies regionally. If a buyer is in an unsupported jurisdiction, checkout shows coming-soon copy and does not proceed to payment; Phase A interest in those regions may still be recorded where allowed, but it is marked as non-convertible or coming-soon demand so that downstream conversion logic never treats it as a sale waiting to happen.
Creating a design is a wizard that runs through five stages — Describe, Projections, 3D model, Block kit, and Save and publish — and it is built to be resumable: when a creator returns to the wizard, the platform loads any existing saved draft or generation state on entry before offering to start a blank draft. Model and source uploads accept only GLB, GLTF, OBJ, and STL files, and the size limit is one hundred megabytes; raster and reference media slots may have their own raster-format validation where those slots exist, but the raster rules never widen the supported model-and-source upload formats. The Describe-stage style presets are configuration data, so applying a preset may seed or append prompt text and set a reference image, but preset labels, palettes, descriptors, swatches, and thumbnails are not hard-coded as product truth.
Projection face slots cover the front, back, right, left, top, and bottom views. The front face is compulsory; the other five are optional, and any face may be user-provided, generated, restored from history, reused from the source, or optionally autofilled. Model generation options are configurable rather than fixed, and model output references accept GLB and GLTF-compatible generated assets so the generation pipeline can evolve without changing the contract. Every AI cost in this pipeline — projection generation, model generation, and block-kit generation — is configurable, and model generation feedback is collected per model tryout and retained for backend pipeline-improvement analysis. The block-kit output bundles the Bill of Materials, Stock-Keeping-Unit and part counts, an estimated cost, an estimated build time, and the assembly steps.
Publication visibility runs through three values — private, unlisted, and public — and the royalty percent on a listing is bounded between zero and twenty-five inclusive, with a zero-royalty listing supporting community-gift copy where the surface chooses to show it. Draft save is available throughout the wizard, before the creator commits to publishing anything.
Home and gallery surfaces can display listing cards backed by live listing metadata, and those cards carry the saved state for the viewer. The listing detail page supports designer and listing-owner attribution, save, share, and report actions, the Phase A interest-reservation call-to-action when Phase A is active, and the add-to-cart or checkout entry point only when the buyer is eligible under Phase A.5 or Phase B. Product-detail mock surfaces that present alternative layouts are modelled as variants pointing at the same source until the product selects one canonical surface. Public listing visibility is determined jointly by the publish visibility value and the owner's authorisation; remix functionality is disabled in Phase A, so remix controls on Phase A surfaces are inert and notify the user that remixes are not available yet.
Promo Studio assets — the scenes, photos, and videos that a listing owner can generate against their own listing — remain private until an authorised listing owner explicitly adds an asset to listing media or downloads it through an authorised action. Listing media created by Promo Studio retains the source scene, prompt, generation job, asset type, and gallery-publication state so that any later question about an asset's provenance can be answered from the record. Promo Studio scene state is scoped to the listing and includes the environment, lens, model placement, camera rig state, optional custom environment media, and the source model and footprint metadata. Promo Studio may be launched only by the listing owner or by an authorised role acting on that listing; public users and buyers cannot start Promo Studio jobs against a listing they do not own. Photo and video generation costs, batch-size labels, duration and aspect choices, the credit balance display, and the top-up copy are all configuration-driven, and the demo credit values that appear in the mock are not business rules. Video generation requires an existing generated photo asset as its source frame. Generated assets may be kept and starred, downloaded, archived or removed where enabled, or added to listing media; adding an asset to listing media never bypasses listing ownership, media validation, or moderation rules.
Phase A listing demand is recorded as an interest reservation, not as a cart checkout, pre-order, order, invoice, receipt, shipment, payout, or payment state. Interest reservations require explicit acknowledgement from the user that the action is non-binding, does not reserve production capacity, collects no card, creates no Stripe object, creates no order, and promises no shipment. Duplicate active interest for the same user-and-listing pair returns or refreshes the existing reservation rather than inflating demand with duplicates. Interest reservations are cancellable where state permits, and they remain audit-visible after cancellation. Phase A.5 conversion from interest to pre-order is not automatic: it requires an explicit invitation, a fresh consent from the buyer, listing-owner or designer terms, moderation and intellectual-property gates, regulatory and product gates, price and support gates, and finally a successful Stripe SetupIntent.
Checkout, when it is active, runs through the Bag, Delivery, Payment, Review, and Confirmation surfaces where the Phase A.5 and Phase B application exposes them. Delivery methods are configurable by jurisdiction; mock labels like standard, express, or collection-point are examples that apply only when configuration returns them, and the delivery price labels visible at checkout are configurable display values rather than hard-coded universal prices. Payment supports saved Stripe card references and new-card verification or capture handled by Stripe; Stripe is the only payment provider, and the accepted-card copy lists only card types Stripe supports in the buyer's jurisdiction. Phase A interest reservations have no payment step at all. Value-Added Tax shown at the review step is calculated from the buyer's jurisdiction. There is no post-checkout manual queue or wait-time metric rule on DomiDo; checkout completes or it does not.
Confirmation is phase-specific. A Phase A confirmation produces an interest-reservation state and explicitly not a pre-order, build-review clearance state, or charged-order state. A Phase A.5 physical-kit confirmation implements Stripe SetupIntent pre-order semantics for invited eligible reservations: the card is verified, no charge is captured, no invoice is raised, no goods are supplied, cancellation is allowed where state permits, and no ship date is promised. Phase B confirmation captures funds through PaymentIntent and creates a charged order with receipts, invoices, and the corresponding downstream events. Saved carts and checkout drafts preserve the cart lines, the checkout step, the jurisdiction, the delivery and Value-Added-Tax configuration version, the validation state, the resume availability, and the discard availability; resuming a saved cart revalidates price, Value-Added Tax, delivery, supported-jurisdiction status, and item availability before any payment runs.
The order surfaces show different content depending on which phase produced the underlying record. A Phase A interest reservation detail shows the item summary, the listing owner, an indicative price or a price-unavailable state, the non-binding acknowledgement, cancellation state, support state, and the conversion-invite timeline. A Phase A.5 pre-order detail shows the card-verification status, the no-capture status, an item summary, an expected price, cancellation state, support state, the gate versions that applied, and the commitment timeline. A Phase B order detail shows payment status, delivery status, fulfilment-readiness status, item summary, charge, jurisdictional Value-Added Tax, refund, receipt, and invoice data where visible. Payment retry is available through Stripe when the Phase B order payment state requires it; Phase A.5 SetupIntent verification failures are handled as card-verification retry, not as payment retry; Phase A interest has no card-verification retry because no card was ever provided. Address change and delivery-preference change are available only while the order state permits them.
Order-life-cycle actions are modelled explicitly. Cancellation, payment retry, address change, delivery preference, return, replacement, issue report, dispute or challenge, and order message submission all use typed action payloads that carry eligibility, validation, idempotency, result status, and timeline or audit output. After a Phase A interest action, a reservation is in one of the active, cancelled, blocked, invited-to-pre-order, converted-to-pre-order, or expired states. After a Phase A.5 checkout, a pre-order is verified, pending verification, failed verification, expired, converted, or cancelled. After a Phase B capture, an order ships immediately, waits because the required blocks are absent from storage, or waits because production is not yet ready to produce the blocks. No ship date is promised for a Phase A interest reservation, a Phase A.5 pre-order, or a Phase B production-readiness wait; the user is notified by email when a later pre-order or order is ready for the next eligible stage.
Return handling supports charging or deducting a return fee when returned blocks are damaged, show wear, are returned for change of mind, or have diminished value. Refunds, return fees, and return deductions are Phase B fulfilment behaviours that update order totals and the corresponding designer royalty and statement records where applicable. Buyer order-update notifications are stored as separate event records with read and unread state; mark-read and mark-all-read actions touch the notification, never the underlying order. Shipment tracking, parcel grouping, ETA changes, delivery-preference choices, carrier labels, refund timing, attachment limits, and report categories are sourced from order records, configuration, or support policy rather than treated as fixed values, and the mock examples in those areas are not rules.
Kits support a build companion payload when an order carries assembly data. The build companion delivers step payloads, progress save, stuck-help and support escalation, finished-build photos, profile-sharing settings, designer-feedback permission, and a separate build-experience rating at a general capability level. The trust pipeline may blacklist or restrict a user for customer extremism or anti-abuse reasons, and any such decision is challengeable through support tickets or dispute processing.
The designer royalty percent on a listing runs from zero to twenty-five inclusive, and the buyer-facing listed price is derived from the base kit price plus the selected royalty markup wherever the listing designer mock displays that relationship; royalty values include Value-Added Tax. Ad-boost budget and spend are represented where visible, but specific amounts are treated as configuration and display data rather than as rules unless they are explicitly product-approved. Designer listing changes preserve the listing's status notices, metrics, and message and action state; the listing editor preserves unsaved and versioned edit metadata, the rules that distinguish editable sections from platform-owned sections, moderation flags, similarity matches, analytics, and the action queue context. Moderation rerun cost and eligibility are configurable, and the mock credit values shown in the design surfaces are not business rules.
Remix in Phase A is inert by design: Phase A remix settings do not enable remix creation, remix split negotiation, or remix payout effects, and if a Phase A user encounters a remix affordance the application notifies them that remixes are disabled in Phase A. Remix split proposals do not affect payout calculation in Phase A.
Designer engagement actions — review replies, listing question replies, FAQ candidates, designer message replies and reports, and claim actions — are allowed only for the owning designer or an authorised support role. These actions preserve moderation and report state, and they do not expose buyer-private account, payment, or payout data. Creating an FAQ candidate from a listing question does not directly publish or mutate Workshop or Help content; the admin content rules continue to govern any later Help article or topic change.
Designer payout settings use Stripe Connect from Phase A.5 onward. Routing, account, and tax-identifier data stay with Stripe wherever the user interface says so, and the platform's local payout settings cover the Value-Added-Tax number, Unique Taxpayer Reference, tax region, payout options, payout request state, minimum payout handling, and payout-readiness status; tax-region choices are configurable. Every payout number — the minimum payout, the payout fees, the schedule labels, and the eligibility delays — is configurable. In Phase A.5 those numbers shape the readiness display and the statement preview; in Phase B they govern actual payout release. Payout on request charges a configurable fee with a default value of two percent, and a payout requested below the configured minimum payout charges a configurable fee with the same two-percent default.
Projected royalties may be recorded against attributed Phase A.5 pre-orders, but actual payout release is permitted only after a Phase B capture and no earlier than thirty days after delivery. Statement archive and export are supported where visible. The platform does not encode a fixed per-block royalty amount, a fixed flat minimum for small designs, a fixed monthly payout day, a fixed weekly payout schedule, a fixed return-reversal window, or a fixed return-rate display; those numbers are configuration, not rules.
Designer sales are modelled across the attributedPreOrder, reserved, sold, disputed, and refunded states. Phase A.5 attributed pre-orders create projected royalty only, and disputed Phase B sales pause or adjust royalty availability according to the configured dispute and reserve rules. Sale-lifecycle dates and states are derived as facts from pre-order, order, payment, delivery, and payout records, not inferred from mock labels. The Stripe Connect state supports not-connected, action-required, active, and new-and-first-sale; requirement labels and remediation copy are safe display labels rather than raw provider requirement payloads. Payout balances distinguish available, pending, in-transit, and reserved balances where each is present. Payout schedule cadence labels, the auto-payout pause and resume behaviour, the availability of payout on request, and the minimum-payout behaviour are all configurable.
Failed payout resolution routes to an authorised Stripe-managed or Stripe-referenced remediation flow and does not expose bank-account secrets in the process. Actual failed-payout remediation is Phase B money-movement behaviour; Phase A.5 may surface onboarding and Know-Your-Customer remediation and payout-readiness errors. Reserve ledger entries record the hold-and-release kind, amount, reason, the linked sale or dispute where one exists, status, and the configuration version that produced the entry. Dispute and reserve outcomes may adjust royalty availability, statement totals, and payout balances; provider dispute fees, reserve percentages, reserve caps, release timings, and grace and hold windows are configurable or omitted, and mock demo numbers in those areas are not product truth. Payout activity notifications cover payout-paid and payout-failed events, reserve-held and reserve-released events, dispute-opened events, and the monthly or periodic statement-availability events where configured.
Cookie preferences are manageable from the footer. The privacy, terms, accessibility, sitemap, and data-request links remain visible from the shared footer and legal surfaces so that a user does not have to navigate into authenticated territory to act on their rights. Newsletter signup captures the consent and the source surface so that the basis for any later communication is recorded. Account privacy changes apply only to the signed-in account performing them. Blacklist and restriction state is visible only to authorised support and trust roles, and to the affected user through dispute or support context where that is appropriate; every support and trust staff action on a restriction is audited.
The public Workshop and Help layer is Docusaurus-generated static content and maintains only the general structure needed for help browsing: topic groups, article kinds, the article index, the article reader, search, related navigation, support entry points, and admin content management. Article topics, article kinds, featured slots, popular slots, and related-and-backlink behaviour are configurable content metadata. Specific article slugs, article bodies, material claims, shipping windows, return-policy figures, designer-application statistics, block counts, manufacturing-capacity claims, and story details are not encoded as business rules — they are editorial content that the Workshop and Help authors maintain.
Only administrators may create, update, publish, unpublish, archive, delete, reorder, or trigger Docusaurus publication for Workshop and Help content. Public users may read published Workshop and Help content, and they may start support conversations where the surface provides a support entry point. Public or signed-in users may also create Help article comments, replies, likes, and reports where the discussion feature is enabled; those are platform backend user-generated discussion records, not Workshop or Help content mutations, and not Docusaurus content changes. Help comment moderation may hide, flag, or remove discussion records according to moderation policy, but it never grants non-administrators permission to create, update, publish, unpublish, archive, delete, or reorder article, topic, or kind content.