DomiDo is, at heart, two ideas working together: an artificial-intelligence design tool that turns a sentence or a 3D model into a structure made of interlocking blocks, and a manufacturing-and-fulfilment operation that makes those blocks and ships them as a kit. The minimum viable product is the smallest version of that pairing the team is willing to put into the world and learn from, and it draws a clear boundary so that everything inside is being built and everything outside is intentionally deferred. The company manufactures blocks and fasteners only; every construction is a user-generated design, and the gallery that opens on launch carries category demonstrations published by Avvyland Limited itself alongside any designs customers choose to publish. This page is the place new readers come to find out what is being built first, how the phased launch works, what flows the application supports today, and where the known gaps still sit.
DomiDo's launch is staged. Phase A is a demo and non-binding interest phase: people can explore the product, design structures, save them, and register interest, but no money is taken. Phase A.5 introduces invited pre-orders that verify a card without charging it, using Stripe's SetupIntent mechanism — a way to confirm a card belongs to the buyer so it can be charged later. Phase B is the physical launch, when manufacturing tooling is paid for, kits start shipping, and the saved cards are charged on dispatch. Phase C, later still, opens the designer marketplace where third-party creators can earn royalties on the designs they publish. Throughout this page, "the MVP" refers to Phase A with the foundations needed to step into A.5 and B.
The MVP is a fully functional application even though it does not yet ship physical kits. Customers can create designs in two complementary ways: by uploading a 3D model (called Mode A) or by describing what they want in plain English and letting the artificial intelligence generate the geometry (called Mode B). Both paths converge into the same twelve-stage processing pipeline that turns geometry into a set of blocks and fasteners. They can browse a content gallery of designs — both early reference designs published by Avvyland itself before the marketplace opens and any community designs that have been published — search by text, voice, or image, like and comment, follow other creators, build collections, and share to social media. They can place a pre-order through Stripe Checkout that, in Phase A.5, verifies the card without charging it; the actual charge happens only when the kit ships in Phase B. They can view their design and the assembly steps in an interactive 3D viewer built with React Three Fiber, the React-Native-friendly Three.js renderer. They sign in with Google, Apple, or Facebook OAuth — there is no email-and-password account.
The mobile and web experience comes from a single codebase. The application is delivered as a Progressive Web App — a website that behaves like an installed application, with offline caching of the assembly viewer and "Add to Home Screen" support. No native iOS or Android binaries ship in the MVP; those come later. Behind the scenes, an administrative dashboard supports the operating team. It surfaces pipeline health, every pending and completed order, gallery moderation queues, customer-support tooling, an artificial-intelligence-credit usage view, and live system health.
Both Mode A and Mode B converge into the same processing pipeline that turns a 3D mesh into a buildable kit. Each stage has a target latency, an expected success rate, common failure modes, a fallback strategy, and a plain-language error message for the user. The stages are import (read the uploaded file — GLB, GLTF, OBJ, or STL up to one hundred megabytes), repair (fix non-manifold geometry, holes, and degenerate triangles, with a signed-distance-field classifier as a fallback when straightforward repair fails), voxelise (convert the mesh into a 3D grid of small cubes), align (rotate the model so the resulting block layout is as efficient as possible), custom voxels (refine boundary voxels at a finer resolution to preserve detail), blockify (choose how to cover the voxel grid with real-world block sizes — three solvers are available, a fast greedy approach, a slower dynamic-programming approach, and a slowest-but-best integer-linear-programming approach, with the pipeline falling back from the slowest to the fastest if needed), interfaces (calculate which faces of which blocks touch each other), features (decide where fasteners go using a simulated-annealing optimisation, with a greedy fallback if it stalls), stock-keeping-unit assignment, validate (check the result against the rule engine and emit structural advisories), assembly (sequence the build and mark any steps that need pre-assembled sub-assemblies), and export (package the final design as data the front-end and third-party logistics provider can consume).
The end-to-end target is a ninety-fifth-percentile latency under thirty seconds for Mode A on the fast solver, and under ninety seconds for the highest-quality solver. The whole pipeline runs twice if the first attempt fails before the design is marked failed and the user emailed.
The launch catalogue is a small set of category demonstrations of what the universal block system can build — early reference designs that Avvyland Limited publishes itself before the designer marketplace opens. They cover a deliberately broad span of use cases (garden borders and raised beds, privacy and screening, utility concealment such as bin shelters and heat-pump or air-conditioning covers, and at least one statement piece) so that early visitors see the breadth of what is possible rather than a single archetype. Each reference design must pass an explicit gate before listing: the full pipeline completes for every solver, the block count stays inside a target range, the greedy result is within fifteen percent of the optimal, the 3D viewer renders cleanly on a mid-range mobile device, every assembly step places exactly one block with no floating blocks in sequence, at least one physical build has been completed from the generated instructions, and a set of lifestyle photographs is in place. These reference designs anchor the early revenue ramp before custom designs and community publications gain traction, but they are demonstrations of the block system — not a hero product catalogue, and not a manufactured product line in their own right. The company never sells anything other than blocks and fasteners; the designs themselves are part of the catalogue precisely because they are constructions of those blocks and fasteners.
Three end-to-end flows define the MVP user experience. In the first (Mode A, upload your own model) the user navigates from the dashboard to "Create New Design", picks an upload source, selects a file, waits while a presigned upload pushes the file to object storage and the pipeline runs (with progress streamed by Server-Sent Events), reviews the result in the 3D viewer, optionally re-runs the pipeline with different solver settings, adds the design to the cart, completes Stripe Checkout, and watches the pre-order or order status update on the account dashboard. In the second (Mode B, describe your design) the user enters a text prompt and optionally uploads a reference image; the system checks the artificial-intelligence credit balance, sends the prompt to a primary image-generation provider (with fallbacks through several alternatives), removes the background, and generates a first projection; the user iterates through up to eight projections, approves them, picks a 3D-model generator, and once a 3D model is produced the flow re-joins the Mode A pipeline. In the third (gallery-driven purchase) the user browses the published gallery — early reference designs and any community designs — opens a design, customises the size on a slider where the design exposes pre-computed scaled variants (so no pipeline run is needed), adds it to the cart, and proceeds to checkout.
The gallery in the MVP is a content gallery, not a marketplace. The distinction matters: the gallery includes design publishing, browsing, multi-modal search (text, voice, image), likes and dislikes, threaded comments, follows, collections, social sharing, and a "Buy This Kit" call-to-action on every design. What it does not include is the economic layer — no designer royalties, no Stripe Connect split payments, no seller onboarding flows, no payouts. Those activate in Phase C with the marketplace. Publishing is optimistic: a design appears in the gallery immediately, and an asynchronous moderation pipeline scans images, descriptions, and comments; flagged content is hidden until reviewed. Search is powered by multiple embedding vectors stored against each design publication — image, description, tag, taxonomy, derived-artefacts, and cross-domain — using vector search on the database, and voice search transcribes audio first and then runs the text-search pipeline. Recommendations in the MVP are global popularity signals (trending, most-purchased, newest, and staff picks); personalised recommendations are deferred.
Even though Phase A does not ship anything, the system already models the operations that follow. Returns have a fifteen-day window (exceeding the United Kingdom's fourteen-day Consumer Contracts Regulations minimum) and run through a seven-step workflow: customer initiates, prepaid label, in transit, inspection, grading, refund, and dispute. Returned kits are graded A through D, where A returns the full value and D rejects the return entirely.
The manufacturer is modelled as a business actor with a lightweight purchase-order workflow: demand monitoring, reorder alert when stock drops below the reorder point, purchase-order creation, status tracking from confirmed through in-production to quality-assurance inspection to shipped to received, goods receipt, invoice and payment tracking, and a seven-day quality acceptance window. Reorder points are seasonal, with safety-stock multipliers that change between peak and off-season periods.
Every excluded feature has been explicitly evaluated and rejected for the MVP. The designer marketplace requires split payments, designer onboarding, royalty accounting, and content moderation tooling far heavier than the MVP carries, and adds value only once a customer base exists to buy from. Photo-to-design (point a camera at a garden and have the artificial intelligence compose into the scene) is a Mode B refinement, not a new capability, so the core hypothesis can be tested without it. United States and European Union market expansion needs a separate fulfilment partner, multi-currency pricing, tax handling, and localised marketing; the United Kingdom proves the model first. Native mobile applications are postponed because the React Native Web build covers mobile and desktop today; push notifications, deeper offline support, and augmented reality are later phases. Combined products that mix DomiDo blocks with third-party materials would transform the company from a block manufacturer into a broader outdoor-construction platform too early. Uniqueness protection based on design embeddings depends on the marketplace existing. Multi-colour blocks multiply stock-keeping units and tooling investment, so a single-colour launch with user-paintable surfaces is more capital-efficient; custom exterior blocks with sculpted faces would require a different manufacturing model entirely. Augmented-reality assembly guidance needs a native application and real-world block tracking and is not needed to validate the core hypothesis. Structural finite-element validation is deferred because the launch reference designs are decorative or utility structures that do not bear loads requiring engineering validation. The business-to-business sales channel needs account management, bulk pricing, and invoicing. Printable assembly instructions are not produced because the interactive viewer with offline caching is superior and a printable parallel would split the content pipeline. Boolean operations on uploaded models add front-end complexity (selection, preview, conflict resolution) that outweighs MVP value.
The MVP defines its own success criteria rather than borrowing them from a later phase. The team tracks early-stage demand signals — pre-orders collected, card verification rate, gallery designs published, pre-order cancellation rate, design-to-pre-order conversion. Phase B activates when projected pre-order revenue clears the manufacturing-tooling threshold, the cancellation rate stays below thirty percent, and card-verification rates are healthy. The MVP exit is gated on platform stability for thirty consecutive days, a minimum order volume, a pipeline success rate above ninety-five percent over a rolling seven-day window, healthy assembly completion rates, a return-and-defect rate below five percent, zero critical or high-severity security findings, a fulfilment service-level agreement, and at least one reference design demonstrating positive unit economics on realised orders.
The team has codified a set of unambiguous decision rules so problems are not debated. Paid spend pauses and redirects to influencer gifting if cumulative orders are too low at the end of week four. Mode B onboarding halts if the pipeline success rate drops below ninety percent on a rolling seven-day window. Paid Google spend is cut and organic posting is doubled if blended customer-acquisition cost exceeds a threshold for any calendar month. Pricing is reviewed if any reference design falls below ten percent of monthly revenue for two consecutive months. User observation sessions are run if assembly completion falls below forty percent at the end of month two. A quality hold triggers if the return-and-defect rate exceeds five percent over a rolling thirty-day window. The primary artificial-intelligence image generator switches if Mode B cost per generation exceeds a threshold for a rolling seven-day window.
If two or more launch gates fail at the second go/no-go decision point, a smaller contingency configuration activates. Baseline B drops to a smaller set of reference designs (garden border, raised bed, privacy screen), removes Mode B entirely (Mode A upload only), restricts the gallery to those reference designs with no community publishing, and revises the order-volume targets downward. The team and core engineering scope stay the same; the front-end work shrinks.
The MVP package has been through a structured review and a number of residual issues remain. The package still behaves like two baselines merged together: the Phase A pre-order MVP and a later physical-launch operating model are sometimes mixed in the same sentence, and until goals, schedules, gates, and validation plans are tagged with the phase they belong to, planning against one date or one deliverable set is risky. The success metrics are biased toward Phase B because the headline scorecard tracks paid orders, cumulative revenue, repeat purchases, returns, and realised gross margin — all things that are impossible to observe during a pre-order phase, so two parallel scorecards are needed: one for Phase A demand quality and content supply, one for Phase B fulfilment, returns, and unit economics. The Phase B trigger is economically under-specified: it is currently expressed as projected pre-order revenue against the cost of manufacturing tooling alone, but the real capital threshold also includes inventory, fulfilment setup, and runway, and SetupIntent-backed pre-orders are not committed cash, so the trigger needs to be a three-part gate of validated demand, committed capital and cash runway, and operational readiness. The Phase A gallery and social feature set is broad — open publishing, direct purchase, text and voice and image search, six embedding types, likes and dislikes, threaded comments, follows, collections, sharing, and multi-section recommendations all sit in the MVP — and for a small team focused on conversion and build completion, simplifying this to publish, browse, simple text search, and direct purchase attribution would reduce risk. User-generated-content compliance is improved in narrative but still under-specified as product contracts; report flows, moderation service-level agreements, appeal flows, and intellectual-property takedown timing need to be implementable behaviour, not just policy text. Schema, interface, and operations text drift in places — design creation and status API contracts, order and pre-order lifecycle semantics, and payment documentation are not all aligned, and several research appendices still carry pre-supersession assumptions about marketplace economics, multi-region revenue, transport choices, printable assembly output, and credit plans. The dependency and validation schedule pre-commits Phase B work before the demand trigger — inventory, tooling, and a fulfilment partner are scheduled too early, and their commitment dates should sit behind the Phase B decision. The artificial-intelligence credit model is inconsistent across documents, and subscription tier definitions and per-operation credit costs need a single source of truth that other documents reference. The team is aware of every item on this list and is working through them.