DomiDo is an AI-assisted modular outdoor construction marketplace developed by Avvyland Limited (United Kingdom). People describe what they want to build outdoors — a planter, a garden bench, a small shelter, a wall feature — or upload a 3D model of it, and the platform turns that idea into a real physical kit at their door. The kit is a set of universal interlocking blocks plus the fasteners and step-by-step instructions needed to assemble the object at home. DomiDo sells universal blocks and fasteners only; every construction shown on the platform is a user-generated design, and the platform's role in those constructions is enablement rather than authorship. DomiDo sits inside a wider product family that also includes Avvyland, a separate interactive 3D environment for visualising and sharing creations.
This wiki is the home of every published project document — product strategy, requirements, architecture, design, compliance, operations, and technology research. It is written for newcomers: no document identifier knowledge, no internal-team vocabulary, no prior context required. The friendliest entry point for anyone entirely new to the project is Start here, which lays out a guided reading path tailored to your role. The shortest possible introduction to the product itself is What is DomiDo?; the long-form story is Product vision; the end-to-end pipeline that turns an idea into a kit is described on How it works; and any unfamiliar term used anywhere in the wiki is defined in the Glossary.
The wiki is organised into nine sections, each with its own folder index. Overview is the plain-language introduction to the project: what DomiDo is, where it is going, how the pipeline works, and the executive summary of the business. Product covers strategy and scope — minimum-viable-product scope, personas and jobs, use cases and user journeys, the business model, pricing structure, go-to-market plan, and the competitive landscape. Requirements holds the full software-requirements baseline, including functional and non-functional requirements, the data and interface contracts, security, audit and logging, user roles, business rules, acceptance criteria, traceability, engineering requirements, the web-mock requirements, and the payment architecture.
The engineering view continues in Architecture, which describes the system overview, the universal React Native and Expo application, the Go backend, the domain and data architecture, integrations, security and operations architecture, the API traceability audit, and the current architecture choices. Design and UX covers the user-experience baseline, information architecture, user flows, the design system and interaction patterns, accessibility, the heuristic and cognitive walkthroughs, error and empty states, mobile usability, wireframes, and branding.
The remaining sections speak to the operating side of the project. Compliance and legal describes product safety, marketplace duties, tax and customs, data protection and privacy, intellectual property, cross-border tax, and the wider legal overview. Operations collects manufacturing and third-party logistics, quality assurance, the phased delivery plan, the Phase A backlog, the beta-launch checklist, the risk and decision register, observability, support and telemetry, sustainability, and the architecture-options discussion. Technology holds the specialised technical research on block design, augmented-reality and 3D viewer technology, assembly-instruction user experience, payment systems, and product-scoring methodology. Reference is the cross-cutting reference material — the full Document index, the Strategic audit, and the Feasibility summary.
Every section is a folder; opening it reveals an index of the topics inside. Every individual topic page is self-contained — it starts with a one-paragraph orientation, explains terms on first use, and ends with cross-links to related topics under a See also footer. Diagrams are inlined directly into the relevant page, with interactive Mermaid renderings for flows and state machines and raster figures for everything else. Information that is private to the company (specific financial figures, individual compensation, named third-party contract terms, personal data) is replaced by qualitative descriptions; public regulatory thresholds, public competitor names, technical choices, and product specifications are kept verbatim.
The wiki documents the project — what DomiDo is, why, and how it is built — and not the surrounding operational machinery. Implementation source code lives in the engineering repository, operational secrets and environment configuration live in the operations system, internal team discussions live in their own tools, and private commercial terms with named third parties live with the contracts themselves. For anything in those categories, the right destination is one of those external systems rather than this wiki.