This page is the consolidated current-state portrait of the DomiDo product as a strategic whole. DomiDo is built by Avvyland Limited (United Kingdom) and sells universal blocks and fasteners only; every construction shown on the platform is a user-generated design. The audit is read by anyone who needs a coherent answer to "what is DomiDo right now, who does it serve, how does the app behave, and where does the strategy land?". It moves from product truth through customer fit, app structure, customer flows, discovery, administration, and ends on the gap between the documented strategy and the working software. None of the sections is standalone — the picture only resolves when all of them are read together.
DomiDo is one platform with one role: an AI-assisted design-to-kit system whose customer outcome is a buildable DomiDo design and the universal blocks and fasteners that build it. The platform makes a design from a text prompt or an uploaded model, runs it through the dd-mesher pipeline, produces a buildable bill of materials, and ships kits of universal blocks and fasteners. Phase A is a public interest beta; Phase A.5 is a gated no-capture pre-order step; Phase B is real fulfilment; and Phase C is a designer marketplace. Each phase is gated and the gates are explicit. A buildable design is the central commercial object. Listings exist in one canonical form, and catalogue, gallery, and custom-uploaded entries are all listings with provenance attributes — where the design came from — rather than separate businesses. The pre-order is one promise: a no-capture reservation in Phase A.5, captured in Phase B, with fresh consent at each transition.
DomiDo sells universal blocks and fasteners only. Constructions are user-generated content, and DomiDo's role in those constructions is platform and manufacturing enablement, not author or seller of record for the aesthetics. The marketplace adds creator economics only when designer terms, payout safety, and dispute handling are in place — not before. The AI design credit subscription is an explicit digital purchase with its own pricing model, separate from kits. Internal commercial discipline reinforces these distinctions: projected uncharged pre-order value is not revenue, the operations layer treats reservations as a demand signal and pre-orders as commitments under no-capture status, and neither is confused with cash. The phase model is not a logbook but the active operating discipline that gates each commercial promise.
The platform serves a small set of distinct personas. Each has a job that DomiDo needs to do better than the alternatives, and the table below lists those jobs alongside what each one looks like for the platform.
| Persona | Job to be done | What that looks like for the platform |
|---|---|---|
| The buyer who wants one outdoor structure | Buy or build one impressive outdoor structure without contractor-level overhead. | A clear, single product story; visible price; "what you receive" block; a trustworthy pre-order contract; a calm path to a finished build. |
| The buyer who values aesthetics and inspiration | Create an aspirational, shareable outdoor outcome. | Editorial-quality curation; real social proof; premium imagery; consistent brand voice; trust in the design and the build. |
| The technically demanding buyer | Use a capable, professional-grade tool. | A credible Mode A upload flow; transparent pipeline; visible structural validation; clean artefact handoff; control over the design. |
| The aspiring designer | Create, publish, and over time monetise designs. | User-and-designer-owns-design terms; clear publishing economics; visible analytics; a transparent payout path when Phase C opens. |
| The time-pressed buyer with a target date | Plan a reliable outcome against an event. | Date-confident timelines; explicit pre-order semantics; reliable status visibility; honest assembly time estimates. |
| The social-first discoverer | Discover socially and act quickly. | Curated discovery surfaces, real engagement, frictionless gallery-to-purchase path. |
The platform optimises around the buyer who wants one outdoor structure as the beachhead. Inspiration-led buyers amplify that beachhead. Time-pressed buyers stress-test the reliability story. The designer persona is served fully only when Phase C opens.
The customer app uses one top-level information architecture: Discover, Create, Cart, and Account. Each top-level mode has one job. Discover is the landing surface, the curated catalogue entry, and the user-generated gallery — the catalogue is a curated discovery mode inside Discover rather than a separate primary section, and the gallery is a curated community layer in Phase A and a fuller marketplace pillar as supply and trust mature. Create is the design entry point for both Mode A (upload) and Mode B (prompt); authentication appears at the point where it is required (save, publish, reserve interest), not at the entry to the flow, so prospective users can explore the differentiating core before any account gating. Cart is the commerce surface and the only place where commerce happens, with the cart state real, persistent, and credible at every step. Account is the lifecycle hub for drafts, listings, saved items, pre-orders, orders, support, and notifications; settings sit inside Account rather than substituting for it. Admin is a separate operating plane, gated by role at the route level — it is not just another consumer branch.
Interrupted state is a first-class concern. Long-running AI flows, pre-order lifecycles, and multi-session assembly all support a clean resume, and the user lands at the next sensible step on return.
Discovery is editorial first: curated catalogue entries, featured listings, and meaningful filters. Search supports the merchandising rather than being the only path to a result. The first-value story is concrete and prominent on Discover, so users see what kind of outdoor structure DomiDo enables before they commit to creating one. Create supports two modes. Mode A is upload: a model or source file flows through the dd-mesher pipeline to produce a draft, the user reviews and refines, and the design becomes publishable. Mode B is prompt or reference: the platform generates a candidate or queues a controlled-beta result, the user reviews, and the design becomes publishable. Both modes save persisted drafts, surface long-running job state with clear progress indicators, and route to a calm review step before publish or reserve. The authentication wall arrives where it is needed — save, publish, reserve — not before.
The review step is honest. Each design carries a "what you receive" block listing block types and quantities, fasteners, assembly instructions, expected delivery window when applicable, and clear ownership and licence statements; the visual review uses the same renderer as the assembly companion. The commerce flow is real, persistent, and credible. In Phase A the only commerce primitive is the non-binding interest reservation, with explicit no-charge, no-order, no-shipment language. In Phase A.5, selected reservations convert to no-capture SetupIntent pre-orders with fresh consent. In Phase B, captured payment, fulfilment, invoice, and shipment proceed. The cart, the review, and the confirmation each match the rest of the experience in fidelity.
The ownership hub in Account is one place. Drafts, published listings, saved items, reservations, pre-orders, orders, payment issues, support, and the next action are unified. Assembly access is differentiated: preview is available immediately for any design, and build-ready state appears when the kit has shipped or arrived. The assembly companion is described in detail on the assembly instructions page — it is interactive, offline-capable, accessible, and able to fall back to a printable PDF, with time-lapse and share features encouraging social proof of finished builds.
Curated catalogue entries and user-generated gallery listings live in one Discover universe. The sourcing logic is internal and not exposed to the buyer, who sees one consistent trust frame across both; provenance attributes (curated, community, original designer) are visible where they matter — on a creator profile or as a designer credit — but do not fragment the discovery experience. Social mechanics fit the platform's stage: in Phase A save and share are first-class and report and support are first-class, while comments and creator follows arrive when the platform has the moderation and incentive infrastructure to make them rewarding. Voice and image search are valuable only once the merchandising and liquidity are strong enough that those inputs feel rewarding.
Creator-marketplace identity — designer profiles, follows, monetisation — is part of Phase C. Until Phase C opens, the platform does not signal creator economics; when Phase C opens, the designer terms, the moderation regime, the payout safety, and the dispute workflow are all in place. In effect the discovery layer is a disciplined amplifier of the core design-to-kit purchase loop in Phase A. As the platform earns scale, supply, and trust, the discovery layer extends into a fuller marketplace pillar; the pivot point is when liquidity (designs that match buyers, buyers that match designs) is strong enough that a discovery loop adds value beyond the curated catalogue.
The administration surface matches the operating reality of Phase A. The Phase A admin cockpit answers a small set of questions: demand quality (who is reserving interest, on which listings, with what intent), the design funnel (who is starting, who is publishing, where they drop), pipeline reliability (jobs in flight, jobs failed, retry counts), light moderation (reported listings, similarity flags, takedown actions), and customer support (tickets, response time, recurring confusions). Manufacturing, returns, deep purchase-order workflows, and revenue dashboards live in Phase B and Phase C admin and are not visible in Phase A. The admin route plane is gated by role at the route level, so admin is a protected operating plane rather than a consumer branch. Operational readiness signals are based on real evidence rather than projected uncharged value: cash and runway, supply readiness, cancellation-adjusted demand quality, charge-success probability, and committed capital — and the launch checklist enforces the boundaries.
The platform's strongest current alignment is in the creation surface (Mode A and Mode B with persisted drafts, job states, and a review step) and in the front-end navigation (a clear top-level information architecture and real route gating). The 3D viewer renders user-generated designs faithfully and supports assembly playback, and the backend's modular monolith and the universal-app shell are aligned with the documented choices in the architecture section. Areas where the working software still needs convergence with the documented strategy are the active backlog: the commerce layer must reflect the phase-aware contract from Phase A through Phase B with a real cart-state model and a real ownership state machine across reservations, pre-orders, orders, shipments, and assembly readiness; the gallery purchase path must maintain credible state from listing detail through reserve or pre-order with the design's licence and ownership transparently described; the admin plane must enforce role gating at the route level and reduce its surface area to match Phase A; the assembly-preview-versus-build-ready distinction must be unambiguous in the user interface; the resume model must be productised and visible across the app; and the synchronisation between documented specification and working software is enforced through acceptance criteria tied to real routes.
The current-state portrait pulls those threads together. DomiDo is one company with one product story: AI-assisted design-to-kit, with universal blocks and fasteners as the only physical good and user-generated designs as the platform's content. The customer is led calmly from discovery to creation to a clear pre-order contract to a unified ownership hub. Discovery is curated and amplified by community signals proportionate to the platform's stage. Administration is a small Phase A cockpit gated by role. The documented strategy and the working software are converging on this portrait, and the remaining convergence work is the active backlog rather than a separate strategic exercise.