This page is the developer-ready work breakdown for DomiDo's public Web/PWA beta. It exists so that a small senior team can ship without reverse-engineering intent from planning reports: each task in this backlog is a self-contained brief, telling the implementer what to build, what data or screen it touches, how to prove it is done, and how to test it. DomiDo is built by Avvyland Limited (UK) and sells universal blocks and fasteners only; every construction shown on the platform is a user-generated design. Phase A collects public demand through non-binding interest reservations only — there are no cards, charges, orders, invoices, shipment promises, payout release, or DomiDo ownership claims over user designs anywhere in this scope. Phase A.5 may invite selected users into no-capture pre-orders, and only after explicit eligibility gates pass.
The backlog uses a single work-tracking model throughout. Each task is a developer brief with a goal, a list of things to build, the inputs and outputs (typically a specific API contract or a specific screen), the done criteria, the tests, and the dependencies on other tasks. Estimates are in senior-implementation hours, no task exceeds eight points, and every task lives under one of the delivery gates listed below. Priorities are launch blocker, required soon after launch or for gated conversion, and useful but cuttable.
The backlog is organised under nine delivery gates that each have a clear completion rule.
| Gate | Completion rule |
|---|---|
| Public beta foundation | App, API, database, storage, configuration, authentication and session, feature flags, health and readiness, continuous integration, and staging deploy work. |
| Discovery | The public user-owned gallery, listing detail, owner attribution, and search, filter, save, share, and report use API data on the trust surfaces. |
| Creation | Mode A upload and Mode B prompt create persisted drafts, jobs, artefacts, progress, errors, and publishable listing inputs. |
| Publishing | Users can publish valid designs with ownership and licence acknowledgement, safety and use-case gates, moderation state, and localisation. |
| Interest reservations | Users can create and cancel non-binding interest reservations. Dashboards and analytics show demand. |
| Operations | Founder dashboard, support, feedback, logs, metrics, alerts, incidents, backup and restore, and rollback are ready. |
| Public beta launch | Production smoke passes. Founder-led acquisition, support, and daily learning loop are active. |
| No-capture pre-order eligibility | Selected listings pass design-owner terms, moderation and intellectual-property, regulatory and product, United Kingdom geography, pricing and support, and Stripe readiness gates. |
| No-capture pre-order conversion | An invited reservation converts to a SetupIntent pre-order with no charge, no fulfilment promise, an idempotent webhook, and a cancellation path. |
The first milestone creates the technical foundation that lets the universal Web/PWA application, the backend, the environments, the sessions, and the feature gates work as one beta-ready product. The work is to build the API runtime foundation with health checks and safe failures, connect the database and create the Phase A data-model indexes, provide app-startup configuration and feature-gate state to clients, connect the universal app shell to backend configuration, build the shared API client with authentication, language, retry, and idempotency support, add beta-user identity and sessions together with admin role checks, add sign-in and beta-session entry points without losing user progress, provision staging and production runtime services, and enforce foundation build, API, environment, and secret-scan checks in continuous integration. Each task in this milestone delivers either an API contract returning screen-ready state, a frontend flow against real API responses, an infrastructure resource with reproducible provisioning, or a quality gate with clear pass-or-fail evidence.
The second milestone lets public visitors browse user-owned designs, inspect listings, save, share, and report content, and understand trust and safety boundaries from real API data. The work is to build the public-gallery listing API with owner attribution and filters, connect the gallery screen to live listing data and discovery controls, build the listing-detail API for media, owner, safety, and action state, connect the listing-detail screen to live data and trust actions, add save, unsave, and share-intent tracking for listings, connect save and share controls across the gallery and listing screens, add listing and media reporting with rate limits and context, connect the report action and submitted state in the discovery screens, prepare launch-ready starter listings with real ownership boundaries, and publish trust, safety, privacy, and non-binding-interest information in the application. The starter listings carry owner attribution, media, tags, safe intended-use notes, no DomiDo ownership claim, and no structural-fitness claim.
The third milestone lets users upload or prompt for designs, run long processing jobs safely, and persist generated model, block-kit, bill-of-materials, preview, and assembly artefacts. The work is to register private media uploads with validation and checksum tracking, configure private object storage with signed access and upload cleanup, build the durable job model and worker-lease mechanism, add job-status, retry, and cancel APIs with safe state transitions, connect dd-mesher processing through a replaceable worker adapter, start Mode A block-kit processing jobs from saved design drafts, connect Mode A upload, progress, retry, cancel, and result states in the application, start Mode B prompt-to-model jobs with budget and timeout limits, connect Mode B prompt creation and generated-draft states in the application, store Mode A and Mode B generated artefacts in the shared draft model, protect expensive model, AI, translation, and voxelisation jobs with budgets and recovery, and cover the creation flows and long-running-job recovery with automated smoke tests. Each job carries its type, owner, resource references, idempotency key, status, steps, progress, lease, attempt count, retry-and-cancel eligibility, result references, artefacts, and a safe error envelope.
The fourth milestone turns a valid draft into a public listing with commerce disabled, persistent owner acknowledgement, blocked-use safeguards, moderation, and consistent translations across user, public, and admin reads. The work is to build saved design drafts for upload, prompt, artefacts, and publish state, resume create flows after refresh, sign-in, or recoverable failures, store user-written text with source language, context, translations, and moderation state, queue translation jobs whenever user-written text changes, connect fake and large-language-model translation providers with retries, redaction, and cost limits, return localised text consistently across public, user, and admin reads, send language preferences and source-language hints from the application, require owner acknowledgement and a limited operating licence before publish, block unsafe or regulated design claims before publishing, convert a valid draft into a public listing with commerce disabled, connect the publish form, review step, and blocked-use guidance, allow owners to edit their own listing metadata and visibility, connect the owner listing editor and the public preview flow, add admin moderation, takedown, owner notice, and audit trail, and connect the founder moderation queue for reported and pending listings.
The fifth milestone stores non-binding reservations and qualifies demand without any charge or order. The work is to store non-binding interest reservations with buyer, listing, owner, and eligibility state, create or reuse interest reservations without cards, charges, or orders, connect the listing interest call-to-action with non-binding acknowledgement, list and cancel a user's interest reservations, connect the reservation dashboard with cancellation and no-charge status, limit reservation abuse and qualify demand without blocking normal users, and test reservation creation, cancellation, blocking, abuse limits, and analytics. Reservations are not orders: there is no card flow, no invoice, no fulfilment promise, and no implicit commitment.
The sixth milestone closes the operating loop. Users can manage their activity, contact support, and submit feedback; the founder can see funnel, queues, incidents, replies, and exports. The work is to build the user-dashboard aggregate for drafts, listings, saved items, reservations, and support, connect the user dashboard to resume key beta workflows, build support-conversation APIs with resource context and idempotent replies, connect user support flows from help, dashboard, and listing or report contexts, capture beta feedback with screen, severity, release, and source context, add lightweight beta-feedback capture to the application, build product-analytics configuration and event ingestion, instrument the public beta funnel and core user actions, build the founder beta-dashboard API for funnel, operations, and blockers, connect the founder beta dashboard with metrics, queues, incidents, and exports, add founder support-management and operational export APIs, connect the founder support queue with replies, status changes, and exports, run the first-user acquisition loop and route prospects into beta flows, and review the first 72 hours of public-beta data and turn the learning into backlog decisions.
The seventh milestone makes the beta safe to operate and safe to recover from failure. The work is to enforce ownership and admin authorisation on every private resource, protect cookie sessions with cross-site-request-forgery protection, origin checks, and secure settings, rate-limit abuse, oversized payloads, and expensive work before cost is incurred, persist idempotency decisions for mutating and payment-adjacent actions, write audit events for security, content, support, reservation, and payment-state mutations, produce structured, redacted logs for requests, jobs, providers, and failures, store alert rules and incident records for beta operations, connect admin incident and degraded-capability views, prove backup, restore, rollback, and feature-flag disable procedures in staging, test security, abuse protection, idempotency, recovery, and log redaction, smoke-test the public beta in desktop and mobile-width browsers, and cut the Phase A release candidate and smoke-test production with payments disabled.
The eighth milestone is Phase A.5. It begins only after Phase A evidence is in place and the pre-order eligibility gates pass for selected listings. The work is to store eligibility-gate state before any no-capture pre-order invitation, let design owners accept pre-order readiness terms before invitations, connect the design-owner pre-order-readiness screen, allow admins to invite qualified interest reservations into no-capture pre-orders, connect the buyer-invitation flow with fresh consent and a decline path, create or reuse Stripe SetupIntents only for valid no-capture invitations, connect no-capture payment-method setup with Stripe states and cancellation, confirm a no-capture pre-order without creating charge, order, invoice, shipment, or payout state, process Stripe SetupIntent webhooks durably and idempotently, let buyers read and cancel no-capture pre-orders before fulfilment starts, show pre-order invitation, active, cancelled, expired, and failed states in the dashboard, and test the full no-capture pre-order flow to prove that no fulfilment or payment-capture state is created.
Every task in this backlog respects the same guardrails regardless of milestone. Backend tasks include request validation, authorisation, durable persistence, safe error responses, idempotency for create-and-update actions, structured logs, and the exact response data the next screen needs. Frontend tasks use the universal React Native and Expo Web client, call the real API, handle loading, empty, error, and degraded states, preserve user context, and work in the desktop web test target. Infrastructure tasks are reproducible for local, staging, and production, document the required environment values, avoid secrets in source control, and leave operator-visible proof that the environment works. Quality-assurance tasks are automated where practical, run in continuous integration or an explicit smoke script, and leave clear pass-or-fail evidence for the release gate. Growth and operations tasks produce real launch evidence, track source and outcome, capture objections or support themes, and feed decisions back into the active backlog.
The backlog is done when four things are simultaneously true: the public Web/PWA beta opens and a stranger can complete the funnel from home to gallery to listing to create to publish to reserve interest to dashboard to support; the founder can operate the beta from a single dashboard and respond to support, jobs, listings, reservations, alerts, and feedback; Phase A.5 conversion is available only for invited reservations that have passed the eligibility gates, and SetupIntent never captures, ships, or creates an invoice; and the evidence pack in the beta launch checklist is signed off by the launch owner.