This page traces the complete journey from "I have an idea" to "I have built it". It is the engineering counterpart to What is DomiDo? — the same product seen through the pipeline that delivers it. DomiDo is developed by Avvyland Limited (United Kingdom) and sells universal blocks and fasteners only; every construction shown on the platform is a user-generated design, so the pipeline below is the machinery that turns those designs into physical kits. The pipeline is deterministic: the same input always produces the same kit, which is what makes the manufacturing economics work and what lets customers trust that the kit on their doorstep will match the preview they approved. The sections that follow walk through the customer's starting point, the conversion engine that converts a 3D shape into block geometry, the validation and packaging that produces a buildable kit, the pre-order and manufacturing flow, and the build companion that supports assembly at home.
Every kit, whatever its starting point, passes through the same conversion engine in the order shown above. The diagram is the canonical reference for any narrative below: each downstream stage operates only on the validated output of the stage before it, and the customer-facing pre-order, manufacturing, and assembly steps sit downstream of the engine's exported bill of materials and instructions.
There are two doors into the platform. In Upload mode, a user with a 3D model from any standard tool uploads a file. The accepted formats are GLB, GLTF, STL, and OBJ; the pipeline does not care which application produced the model — what matters is that the file conforms to one of those exchange formats. In AI mode, a user without a 3D model describes what they want in plain language and optionally attaches reference imagery, and the platform spends the next phase building a model from the description. That phase has two stages. Projection generation produces a set of canonical views of the imagined object — front, back, sides, top, bottom, plus two oblique angles — with each view automatically checked for quality; the user is shown the set, can accept all or reject individual views, and can request a regeneration for views that miss the mark. 3D model assembly then composes the approved view set into a single coherent 3D model using AI 3D generation, applies photorealistic textures, and hands the composed model to the conversion engine in the same form an Upload-mode model arrives. If any AI stage fails, the customer is not charged for the failed run — the per-generation credits are refunded automatically — and partial progress is preserved so the user can resume rather than restart.
Once a 3D model enters the engine, the importer loads it and produces a normalised internal representation. For GLTF or GLB inputs the importer traverses the scene graph, composes parent transforms with each node's local translation, rotation, and scale, extracts triangle primitives, reads positions and indices in whichever component type the file provides, and produces a single normalised triangle mesh in the platform's internal coordinate system. Unit conversion is applied if needed (a model authored in metres is scaled to the canonical millimetres), a ninety-degree rotation aligns the source coordinate system (GLTF is Y-up) with the platform's Z-up lattice convention, and mesh-analysis utilities measure surface area, volume (by the divergence theorem), boundary edges, non-manifold edges, and other invariants that subsequent stages will need.
Real-world 3D models are imperfect, so the repair stage diagnoses the input and, where possible, fixes it. Diagnosis counts boundary loops (edges shared by only one triangle), non-manifold edges (edges shared by more than two triangles), degenerate triangles (zero or near-zero area), and isolated vertices (not referenced by any triangle), producing a structured report. Explicit repair then runs a five-step sequence: vertices within a tiny epsilon distance of each other are welded together using a spatial hash for efficiency; duplicate triangles are removed (canonical sorting of vertex indices feeds the hash); degenerate triangles are removed; holes are filled where their boundary loops are small enough to be unambiguous (boundary loops larger than a threshold are presumed intentional — a door, a window, a deliberate opening — and left alone); and unreferenced vertices are removed with indices remapped. When explicit repair cannot produce a watertight result, the pipeline falls back to implicit solidification — a winding-number and signed-distance-field based inside-or-outside classification that produces a guaranteed-clean mesh at the cost of some surface detail. The repair stage's report flags whether the final mesh is watertight, what proportion of the original volume was preserved, and whether implicit fallback was needed.
The smooth surface mesh is then voxelised: converted into a regular grid of small cubes. Voxel size is configurable but defaults to twenty-five millimetres in the model's units; the interior is filled by default, since most outdoor structures are solid for the purposes of block-fitting, but hollow voxelisation is supported where the geometry calls for it. This is the bridge between continuous geometry (the mesh) and discrete geometry (the lattice the block library lives on). Everything downstream operates on voxels.
The voxel grid is aligned to the block lattice. Alignment chooses an origin that minimises boundary irregularities and an orientation that maximises the area covered by standard block geometries; this is where the model "settles" onto the manufacturing grid. Where the voxelised surface meets the boundary of the block grid, individual voxels may need custom geometry — a voxel that is partially inside and partially outside the desired shape — so the pipeline computes a sub-voxel sampling at a configurable resolution and produces printable custom boundary voxels for the cases where a standard block cannot fit.
The voxel grid is then decomposed into blocks. The block library at launch contains a set of universal block dimensions (from 1×1×1 inch up to 2×8×4 inch), and the blockification algorithm greedy-fits larger blocks first, balances structural integrity against block count, and respects the block-constraint configuration. The solver runs in one of three modes. Fast mode completes in under five seconds using a greedy heuristic and is useful for early-stage iteration. Balanced mode completes in under fifteen seconds and adds local-search refinement, and is the default. Best mode completes in under sixty seconds and uses integer linear programming for minimum block count. The user can request a specific solver mode.
For every adjacent pair of blocks, the pipeline records the interface — which face of one block meets which face of the other, in which orientation. The interface catalogue feeds the fastener assignment in the next stage and the assembly instructions later on. Beyond connecting interfaces, blocks may carry features: drainage holes for planter blocks, wall-mount threads for cladding blocks, finish surfaces for visible faces. The features stage assigns these to the appropriate blocks based on the design's intent — a planter design surfaces drainage features on its base layer, while a wall design surfaces mount features on the cladding face.
Each block in the layout is then mapped to a specific stock-keeping unit in the block library. SKU assignment honours the manufacturing constraint that the universal library has a finite catalogue of distinct block geometries; the design must compose to that catalogue. The complete design is finally checked against the rule catalogue. Rules cover structural integrity (no floating blocks, no overhanging configurations without support), assembly feasibility (every step places exactly one block, and the build order produces a stable partial structure at every step), and manufacturing feasibility (every block in the design is in the production-ready stock-keeping-unit set). A failing validation produces a diagnostic report and either an automatic remediation, where the rule supports it, or a user-facing error.
The validated design is converted into a step-by-step assembly sequence. The sequence respects gravity (you cannot place a block where it would have no support yet), accessibility (you cannot place a block whose location is blocked by an earlier block), and clarity (a step is the smallest unit a builder can understand at a glance — typically one block, occasionally a small grouped placement). For each step the plan records the block (stock-keeping unit and orientation), the fastener (type and quantity), the position relative to the prior steps, and a short instruction. The pipeline then emits a bundle that contains the bill of materials (stock-keeping unit and quantity, fastener list, finish parts), per-block placement data, the assembly sequence with timing estimates, and a 3D preview that the in-app viewer can render.
From the customer's side the pipeline is invisible. They see a live preview of their design rendered in the 3D viewer as soon as the pipeline completes, a bill-of-materials summary covering total block count, fastener count, kit weight, estimated build time, and kit price, and the assembly sequence as a step-through experience with the previous and next blocks called out and a "stuck on this step" button that surfaces common failure modes for that step. They can iterate before pre-ordering — change a dimension, add a tier, swap a finish — and each iteration runs the pipeline again. They pre-order when they are happy.
Pre-orders are placed against verified payment cards. Card verification is performed via a Stripe SetupIntent: the card is checked and stored under the customer's payment-method record, but no funds move. See Payment architecture for the full state machine. Each design has a manufacturing threshold, and when accumulated pre-order interest clears it the design is "cleared to build". Cards are then converted to charges via Stripe PaymentIntent, the customer is notified before any charge, and the order moves through a "build-ready" state into the warehouse. Picking is done at a third-party logistics warehouse: each order is unique, a specific combination of universal blocks per the bill of materials, so kitting is per-order rather than from pre-packed boxes. The pick list is generated from the bill of materials and feeds a labelling system that groups blocks by build step, so the customer opens the box and finds "Step 1 blocks" already sorted. The kit ships with one or two boxes depending on size, a fastener pack, a finish kit where the design specifies one, and a printed quick-start card whose QR code opens the build companion.
The build companion is the in-app assembly assistant. It is mobile-first, works offline once loaded, and walks the customer through the kit block by block. For each step the companion shows the blocks needed (with their printed numbers), the join pattern, and a small 3D preview that the user can rotate, with a "play step" animation showing the join in motion and a "stuck on this block" button that opens a side panel with photographed examples of the most common failure modes for that specific step. Progress saves automatically, so the user can pause, leave, come back days or weeks later, and resume at the block they left. When the last block clicks in, the companion prompts the customer to photograph the finished build; the photographs are shared back to the designer (when permission is granted) as feedback, and the customer's profile gains a built-it record.