The gantt shows the phase windows of the current delivery plan. Foundations run through the engineering setup, the universal app baseline, and the backend domain skeleton. Phase A opens the public interest beta. Phase A.5 layers verified-card pre-orders and designer-side commerce readiness on top of the interest flow without taking payment. Manufacturing readiness produces the production tooling, qualifies the third-party logistics partner, and gates the Phase B activation. Phase B begins capturing payments and shipping kits. Phase C activates the designer marketplace economics. Each band is a window of effort, not an exact calendar commitment; the actual timing is driven by the decision checkpoints described later on this page.
DomiDo is delivered in three explicit phases that together carry the platform from public learning to real fulfilment. Phase A is a public interest beta: strangers can create, publish, browse, save, share, and express non-binding interest in user-owned designs. Phase A.5 is a gated no-capture pre-order step, in which selected interest reservations can be invited to a Stripe SetupIntent — a way to verify a card without taking any money — once explicit gates are passed. Phase B is real fulfilment: cards are charged, invoices are issued, blocks are shipped, and eligible designer payouts are released. DomiDo manufactures and sells universal blocks and fasteners only; every construction shown on the platform is a user-generated design, and the platform is built by Avvyland Limited (UK). This page is the current delivery plan that ties all of that together. It is a startup delivery plan, deliberately stripped of corporate process overhead and optimised for shipped product, real customer intent, and a credible path to paid fulfilment.
DomiDo opens Phase A when strangers can create, publish, browse, save, share, and express non-binding interest in user-owned designs; it enters Phase A.5 only when selected interest can be converted into Stripe SetupIntent no-capture pre-orders with fresh buyer confirmation and the designer-terms, moderation, and regulatory gates complete; and it enters Phase B only when the manufacturing, fulfilment, and consumer-law foundations are in place.
The launch surface is a universal React Native application tested first as a Web/PWA on desktop and mobile-width browsers, with the architecture kept compatible with later iOS and Android targets. Store delivery comes after Web/PWA beta evidence, not before it. The Phase A demand model is the InterestReservation: non-binding, with no card, no charge, no order, no invoice, and no shipment promise. Phase A.5 demand conversion invites selected reservations into Stripe SetupIntent no-capture pre-orders only after explicit gates pass and the buyer provides fresh consent. Users and designers own the designs they create or publish; DomiDo receives only the limited licence needed to host, process, translate, moderate, display, validate, and later manufacture eligible designs after explicit terms. DomiDo's role across all of this is the platform and manufacturing-enablement system, not the owner, author, or seller of record for user aesthetics, and not a curator claiming authorship.
The public gallery is active in Phase A on top of user-owned listings; DomiDo may feature listings but must never imply ownership. Physical kit geography is United Kingdom only for Phase A.5 pre-order conversion and Phase B fulfilment until expansion gates are approved. Active physical use cases are limited to free-standing and decorative configurations, plus safe validation of upload-based designs; cladding, structural, electrical, wet-area, child-use, and regulated uses stay blocked. Phase B fulfilment — capture, shipment, returns, invoices, and payout release — sits outside both Phase A and Phase A.5 and starts only when its own gates pass. Paid AI design credits stay disabled unless the tax, refund-and-cancellation, payment, and consumer-law gates are complete.
| Phase | What a user sees | What is not allowed |
|---|---|---|
| Phase A — Public Interest Beta | Public web app, design creation, publishing, user-owned public gallery, non-binding interest reservations, dashboard, founder operations, support, telemetry, moderation and reporting. | Cards, charges, pre-orders, orders, invoices, shipment dates, payout claims, DomiDo ownership claims. |
| Phase A.5 — Gated No-Capture Pre-orders | Selected reservations can be invited to a SetupIntent pre-order after the buyer reconfirms and design-owner and regulatory gates pass. | Automatic conversion, capture, shipment promise, payout release, unmanaged cross-user commerce. |
| Phase B — Real Fulfilment | PaymentIntent capture, receipts and invoices, fulfilment, shipment, returns, delivery support, designer entitlement and payout release where eligible. | Launching before Phase A.5 evidence and fulfilment readiness gates pass. |
The arrows between phases are not automatic. Each phase opens only when its gates are met, and the gating decision is made explicitly rather than implied by a calendar slip.
Phase A public beta is live only when every aspect of the public app, the underlying universal foundation, and the operating loop is working together. The production Web/PWA must open on desktop and mobile-width browsers without founder help, and the navigation, API client, authentication and session handling, feature flags, configuration, and responsive layout must be compatible with later iOS and Android targets. The public listings shown in the gallery come from seeded or user-published data, clearly carry creator and owner attribution, and make no DomiDo ownership claim. Create Mode A lets a user upload a supported model or source file, run the dd-mesher path or controlled beta path, preview the result, save a draft, and publish if valid; Create Mode B lets a user submit a prompt or reference, receive an automated or controlled beta result, save a draft, and publish if valid. Publishing persists visibility, title, description, tags, media, safety and use-case gates, owner licence acknowledgement, and moderation state.
Signed-in or session-backed users can reserve non-binding interest for any public listing with an explicit acknowledgement and no payment step at all. The user dashboard shows drafts, published listings, saved listings, interest reservations, support state, and beta notifications. The founder dashboard shows sign-ups, design starts, published listings, listing views, interest reservations, cancellations, failed jobs, support, feedback, incidents, and the top funnel drop-offs. Analytics ingestion captures critical events through a backend-owned event dictionary without blocking user flows. Support is real, not theatrical: users can contact support and report content, and the founder can triage, reply, and track first-response state. The legal and trust surface — terms, privacy, cookies, the user-generated-content licence, the interest-reservation disclaimer, product-safety boundaries, support, and reporting copy — is live before launch. The reliability foundations — upload limits, job states, retries, idempotency, rate limits, alerting, backup and restore, and rollback — are good enough for public beta even though they will continue to harden through Phase A.5 and Phase B.
Seven flows have to work end to end before the public beta can open. Discover (home, gallery, search, filter, sort, listing detail, save, share, help and trust routes) lets strangers understand the offer and inspect real public designs. Create (Mode A upload and Mode B prompt, each producing persisted drafts and job states) proves the technical wedge and gives users ownership of output. Publish lets users push valid designs to the gallery with visibility, owner attribution, licence acknowledgement, and moderation state, creating supply and public proof without DomiDo pretending to own designs. Reserve interest lets a user express non-binding demand for any eligible public listing, including another user's public design, so that demand is measured before legal, payment, and manufacturing complexity is taken on. Manage exposes drafts, listings, saved items, reservations, support, and notifications in a user dashboard so the beta feels real and recoverable. Operate gives the founder a single dashboard for funnel, jobs, listings, reservations, support, feedback, alerts, and exports, so a small team can run the beta manually without bureaucracy. Convert later — used only when Phase A.5 opens — invites a selected reservation into a SetupIntent pre-order with fresh buyer consent and gate evidence, creating a controlled bridge from interest to real commercial intent.
The endpoints below are the minimum useful launch surface; anything more has to directly serve Phase A learning or Phase A.5 conversion.
| Endpoint | Phase | Purpose |
|---|---|---|
GET /api/health, GET /api/livez, GET /api/readyz |
A | Uptime, release, and dependency smoke. |
GET /api/app-shell |
A | Navigation, user summary, feature flags, public configuration. |
GET /api/config/product-events |
A | Backend-owned analytics event dictionary. |
GET /api/config/translations |
A | Supported languages and fallback policy. |
POST /api/analytics/events |
A | Product analytics ingestion. |
GET /api/gallery/listings |
A | Public gallery list, search, filter, and sort. |
GET /api/listings/{listingId} |
A | Listing detail with owner attribution, localised fields, safety and use-case state, interest call-to-action state. |
POST /api/listings/{listingId}/interest |
A | Create or refresh a non-binding interest reservation. |
GET /api/me/interest-reservations |
A | A user's active and cancelled reservation list. |
DELETE /api/interest-reservations/{reservationId} |
A | Cancel a non-binding reservation. |
POST /api/media/uploads |
A | Register safe uploads for source files and public media. |
POST /api/design-drafts, PATCH /api/design-drafts/{draftId} |
A | Draft create and update. |
POST /api/design-drafts/{draftId}/model-jobs |
A | Start Mode A or Mode B model generation or processing. |
POST /api/design-drafts/{draftId}/block-kit-jobs |
A | Start dd-mesher and block-kit processing. |
GET /api/jobs/{jobId} |
A | Poll long-running generation, voxelisation, or translation tasks. |
POST /api/jobs/{jobId}/retry, POST /api/jobs/{jobId}/cancel |
A | Safe user or admin job recovery. |
POST /api/design-drafts/{draftId}/publish |
A | Publish a user-owned listing after validation. |
GET /api/me/dashboard |
A | User dashboard aggregate. |
POST /api/support/conversations |
A | User support and report entry. |
POST /api/beta/feedback |
A | Structured beta feedback. |
GET /api/admin/beta |
A | Founder dashboard. |
GET /api/admin/interest-reservations |
A | Demand review, filtering, export, and qualification. |
POST /api/interest-reservations/{reservationId}/invite-preorder |
A.5 | Admin invites a reservation to gated no-capture pre-order. |
POST /api/checkout/setup-intent |
A.5 | Create or reuse a Stripe SetupIntent only for invited eligible reservations. |
POST /api/checkout/confirm |
A.5 | Confirm a no-capture pre-order with fresh buyer acknowledgement. |
POST /api/stripe/webhook |
A.5 and B | Idempotently record SetupIntent and PaymentIntent events. |
GET /api/pre-orders, DELETE /api/pre-orders/{preOrderId} |
A.5 | Buyer reads and cancels no-capture pre-orders before Phase B. |
| Data | Required fields |
|---|---|
| User and session | Email or session id, authentication provider, locale, consent state, source attribution, roles. |
| Listing | Owner user id, owner display name, title, slug, localised text, category, tags, media, design artefact references, safety and use-case gates, moderation state, visibility, interest summary, commerce state. |
| Design draft | Owner, mode, source file or prompt, source language, job references, artefacts, validation state, publish state. |
| Job | Type, owner, resource references, idempotency key, status, steps, lease, attempts, progress, safe error, artefacts, retry and cancel eligibility. |
| Interest reservation | User and session, listing id, design owner id, status, non-binding acknowledgement, indicative price snapshot if any, jurisdiction, intended use, source, cancellation reason, conversion-invite state. |
| Pre-order | Phase A.5 only: source reservation, buyer, listing, design owner, SetupIntent references, expected price snapshot, no-capture acknowledgement, gate versions, cancellation state. |
| Translation record | Source text, source language, field context, target variants, provider and status, stale state, moderation flags. |
| Event | Event name and version, route or screen, resource references, user or session where allowed, consent class, source attribution, timestamp. |
| Support and report | User or session, resource references, category, priority, messages, owner, translation state, first-response state. |
| Alert and incident | Severity, owner, trigger, state, impacted capability, runbook action, correlation id. |
Three environments are kept in step. Local exists for fast development and AI-assisted iteration, where mock or fake providers are allowed, seeded data is required, and no real secrets ever live in source. Staging is a full beta rehearsal with a production-like database and storage, Stripe in test mode, an analytics test project, and a fake translation option for offline reproducibility. Production is the public beta itself: no card flow runs in Phase A, Stripe goes live only for Phase A.5 after the launch checklist passes, and alerts and support are active throughout. Environment variables are documented in .env.example or the deploy secret manager, production secrets are never committed, and staging has to be good enough to run the launch smoke before production.
Branching keeps main releasable. Feature branches are short-lived (normally under forty-eight hours), pull requests are required for code going to main, and the founder or chief technology officer (CTO) can merge emergency fixes after verification. Release tags follow phase-a-interest-beta-YYYYMMDD.N, then phase-a5-preorder-YYYYMMDD.N; the application version is 0.x until beta, 0.9.0-beta.N for Phase A, and 0.9.5-preorder.N for Phase A.5. Feature flags cover betaMode, publishing, interestReservations, phaseA5Preorders, modeB, paidAICredits, and adminBeta. Rollback is either a tag revert or a flag disable, and migrations stay backward compatible during launch. A new feature only enters if it increases acquisition, creation, publishing, reservation, support quality, or Phase A.5 conversion readiness.
The release strategy moves the beta through release candidate 1 (staging can run home, gallery, listing, create, publish, reserve interest, dashboard, and support), release candidate 2 (only blocker fixes, trust copy, telemetry, support, moderation, and mobile issues remain), and a private rehearsal in which ten invited users complete the Phase A funnel on real devices and the founder support workflow holds up. Public interest beta follows with production launch, founder-led outreach, live monitoring, and daily bug and conversion cuts. The Phase A learning review runs after 72 hours and weekly thereafter, looking at sign-ups, design starts, published listings, reservations, and support themes. Phase A.5 readiness is reached only after the designer terms, moderation and intellectual-property gates, regulatory and product gates, SetupIntent flow, and support copy pass; the Phase A.5 launch then invites selected reservations to no-capture pre-orders with no automatic conversion and fresh buyer consent always required.
The test strategy covers eight surfaces. Unit tests cover authorisation, validation, interest-reservation state, job state, translation state, idempotency, and rate limits. Integration tests cover upload, process, and publish; listing reads; interest create and cancel; dashboard data; support and feedback; and analytics. Phase A.5 payment tests cover SetupIntent invite, creation, strong customer authentication, webhook duplicate delivery, failed verification, pre-order cancellation, and the no-capture guarantee. Browser smoke covers Chrome desktop, Safari desktop, and 390-pixel and 430-pixel mobile-width Web/PWA. Pipeline tests cover at least three valid samples and one invalid sample for Mode A, plus Mode B queued, success, and degraded states. Analytics tests verify that critical events are visible in the founder dashboard and the analytics provider. Security sanity covers private-data authentication, cross-site-request-forgery and origin checks, upload limits, expensive-work rate limits, webhook signatures, and the secret scan. Reliability smoke covers job retry and cancel, provider timeout, degraded database response, alert smoke, and the backup-and-restore rehearsal.
Completion is checked stage by stage. A1 foundation is complete when the application and API deploy to staging, the database and storage work, and configuration, flags, authentication, session, and analytics basics are live. A2 public gallery is complete when listings render from the API with owner attribution, localised and fallback text, save and share, reporting, and the interest call-to-action state. A3 creation is complete when Mode A and Mode B create persisted drafts, jobs, and artefacts, or clearly indicate degraded beta states. A4 publishing is complete when valid drafts publish to the public gallery with owner acknowledgement, licence grant, safety gates, and moderation and reporting. A5 interest reservations is complete when users can create and cancel non-binding reservations and dashboards and analytics show demand. A6 operations and safety is complete when support, feedback, admin, telemetry, logs, alerts, rate limits, idempotency, backup and restore, and rollback all pass smoke. A7 public beta is complete when production smoke passes and the founder has outreach, support, and triage process ready. A8 Phase A.5 gates is complete when designer terms, intellectual-property and moderation, regulatory and product, pricing, SetupIntent, webhook, and support gates pass. A9 no-capture pre-order conversion is complete when an invited reservation converts to a SetupIntent pre-order without charge, without duplicate records, and without a fulfilment promise.
Success metrics are tracked at launch week and at the thirty-day mark.
| Metric | Launch-week target | First-30-days target |
|---|---|---|
| Signed-up users | 50 | 500 |
| Design starts | 25 | 500 |
| Saved drafts | 15 | 300 |
| Published public designs | 10 | 100 |
| Listing views | 250 | 5,000 |
| Interest reservations | 15 | 250 |
| Reservation cancellation rate | Under 15 percent | Under 20 percent |
| Support first response | Same day | Same business day |
| Phase A.5 invite acceptance | Not applicable until gates | Roughly a third of invited users |
| Phase A.5 SetupIntent conversions | Not applicable until gates | A few dozen selected conversions |
The interpretation of these metrics is simple: weak sign-ups point to an acquisition problem; users who browse but do not create point to a weak offer or weak creation entry; users who create and publish but do not reserve interest point to weak trust, listing quality, or public demand; and strong reservations make Phase A.5 the next priority.