DomiDo is an AI-assisted modular outdoor construction platform: a customer describes what they want or uploads a 3D model, and the platform turns that intent into a physical kit of universal interlocking blocks and fasteners with assembly instructions. This page introduces the platform from a newcomer's point of view — what the moving parts are, how they fit together, and why the architecture is shaped the way it is. The reader should leave the page with a clear mental model of a single universal customer application sitting in front of a Go backend, a MongoDB Atlas data plane, an object-storage tier for media and artefacts, and a thin adapter layer for external providers, with everything governed by an explicit phase model that controls what is actually allowed to happen at any given moment. Detailed implementation rules live on the rest of the section's pages; this page is the map.
There is one universal customer-facing application built with React Native and Expo, rendered as a Web Progressive Web App today and packageable for iOS and Android when those phases open. The app talks over REST to a Go backend that owns all business logic, persistence, and provider integration. The backend stores its records in MongoDB Atlas, uses Atlas Vector Search for semantic discovery, keeps large media in S3-compatible object storage, and calls external providers — Stripe for payments, the OAuth providers for sign-in, AI providers for projection, model, promo, and translation work, and a third-party logistics partner for fulfilment when Phase B opens — through a thin, isolated adapter layer. Workers run alongside the API server in the same Go service and pick up long-running jobs from MongoDB; the frontend never talks to providers directly, except where a provider owns a secure hosted flow that the user is meant to interact with in-place.
The diagram is read from the top down. At the top sits a single client codebase that compiles to three runtimes; today the required runtime is Web and Progressive Web App on desktop, with iOS and Android preserved by the universal architecture. The Go service in the middle is one binary running two processes: an HTTP API server that handles request-response work, and a worker loop that picks up long-running jobs and outbox events. The data plane underneath is split between MongoDB Atlas (business records, jobs, audit, outbox), Atlas Vector Search (semantic discovery against the same documents), and object storage (media, models, and large artefacts that should never sit inside the document database). External providers sit to the side: the synchronous ones (Stripe and OAuth) are called by the API server; the asynchronous ones (AI generation, language-model translation, Docusaurus, fulfilment, email and support) are called by the worker loop; Stripe also calls back into the API server through webhooks.
The architecture is intentionally product- and interface-first: it defines component boundaries, data ownership, phase gates, security posture, and operating needs without making any deferred infrastructure product mandatory. The goal is a lean, phase-governed system that a small team can ship quickly and maintain without enterprise ceremony. Several core principles fall out of that goal. The product target is universal — one React Native and Expo application is compatible with Web and Progressive Web App, iOS, and Android, with Web and Progressive Web App on desktop plus mobile-width browser smoke as the current delivery and test target. The canonical API contract lives in the requirements section; architecture references it and never duplicates it. Every visible future-phase capability is controlled by a server-side phase gate, so the mere fact that a button is visible in the UI does not imply active money movement, fulfilment, shipment, or payout release. Infrastructure products are implementation choices until separately approved: the active architecture defines durability needs, observability needs, and recovery objectives rather than vendor mandates. Simple modular boundaries are preferred over distributed-service complexity, because a small team has to run this.
DomiDo ships in three product phases that behave as architectural boundaries rather than user-interface flags. Each phase changes what the system actually does, even when the same routes and screens remain visible.
| Phase | What the system does |
|---|---|
| Phase A | Public interest beta on Web and Progressive Web App. Active modules: public discovery, the user-owned gallery, the create-and-publish flow, non-binding interest reservations, the buyer dashboard, support and reporting, legal and trust pages, telemetry, and beta operations for the founder and administrator. No card collection, no charge, no order, no invoice, no shipment promise, no payout release, and no DomiDo ownership claim on user-created designs. |
| Phase A.5 | Gated no-capture pre-order and supply activation. Selected reservations can be converted to no-capture pre-orders backed by a verified card through Stripe SetupIntent. Listing-owner terms, profile and listing qualification, Stripe Connect and Know Your Customer preparation, projected entitlements, statement previews, and payout readiness become live. Still no captured charge or payout release. |
| Phase B | Real fulfilment. Captured payment via PaymentIntent, order conversion, manufacturing and third-party-logistics handoff, shipment, receipts and invoices, returns, replacements, disputes, the build companion, and actual payout release. |
| Phase C | Later marketplace expansion: remix economics, split royalties, advanced marketplace flows. Data placeholders only at first. |
| Native deferred | iOS and Android release rails and app-store billing. Not part of the current Web and Progressive Web App beta acceptance, but the universal app architecture preserves them. |
The implementation may include future-phase code paths before activation, but every such path is blocked by server-side phase state and testable feature gates so that the platform cannot accidentally graduate behaviour by a UI mistake alone.
The system is structured as eight logical components, each owning a clear responsibility and a clear interface. The universal app client is the user-facing React Native and Expo application, rendered to Web and Progressive Web App, iOS, and Android, and it owns the shell, navigation, the modal system, production components, feature gates, and local UI state. Transitional evidence is the set of mock-derived React and DOM wrappers carried across from an earlier Vite prototype; it serves as temporary Web desktop visual and workflow evidence while production React Native modules replace it, domain by domain. The API boundary defines the REST resources, validation, authentication and session context, idempotent mutations, and the UI-ready snapshots returned to the app. Domain services contain the business logic for the catalogue, design drafts, generation jobs, multilingual user-generated-content translation, interest reservations, Phase A.5 checkout and pre-orders, orders, designer and listing-owner commerce readiness, help and support, account, and audit.
The persistence boundary sits behind repositories and provides durable storage with transactional consistency for commerce commitments and audit records. The async work boundary handles translation, generation, media processing, publication and export, email and support notifications, and later fulfilment sync, all driven through a job system with leases and retries. The integration boundary contains every external-provider adapter — Stripe, OAuth, AI generation, language-model translation, media storage, Docusaurus publication, email and support, analytics and feature gates — and is the only place that talks to providers, except where a provider owns a secure hosted flow that the user must interact with directly. The operations boundary covers configuration, secrets, backup, monitoring, alerting, audit access, and incident response.
A typical request flows through these boundaries as follows: the client makes a REST call against the API boundary; the API boundary validates, authorises, and hands off to domain services; the domain services read and write the persistence boundary, enqueue work into the async work boundary, and write audit events; and the integration boundary makes the outbound provider calls when they are needed.
Two practical consequences fall out of this shape. HTTP handlers do not run heavy mesh processing, voxelisation, blockification, or external AI calls inline; they validate, authorise, create or reuse an idempotent job, and return a job reference, while workers do the heavy work. Mutations that create commitments, run generation, publish assets, change payout readiness, or affect orders are idempotent — the same request repeated does not create duplicate state.
The architecture optimises each phase for the right learning loop. Phase A optimises for beta learning and customer acquisition: quick feedback loops, user-owned public supply, reliable interest reservations, analytics-ready journeys, and safe rollback through feature gates. Interest reservations are durable, non-binding demand signals with no card, charge, order, invoice, shipment promise, or pre-order semantics — but the system still stores enough state to prove acknowledgement, listing-owner attribution, cancellation state, anti-abuse controls, demand source, and Phase A.5 conversion eligibility. Phase A.5 converts only selected, eligible interest into no-capture pre-orders and prepares the supply side before real fulfilment; buyer fresh consent, listing-owner terms, moderation and intellectual-property checks, regulatory and product gates, projected entitlements, and payout readiness are all first-class architecture concerns at this phase. Phase B activates only after Phase A and A.5 readiness gates pass; capture, shipment, receipts, returns, the build companion, and payout release are Phase B behaviours. Multilingual user-generated content is part of the Phase A foundation: source text saves immediately, translation runs asynchronously through backend workers, and read APIs return backend-resolved text or fallback for Web and Progressive Web App now and for native targets later.
Five quality rules apply across the platform. Simple modular boundaries are preferred over distributed-service complexity, because the team that has to operate the system is small. Money, tax, delivery, payout, reserve, dispute, generation-cost, and supported-content-language values come from configuration or from source transaction state — never from hard-coded constants — so that a launch into a new jurisdiction is a configuration change rather than a code change. Mutations that create commitments, run generation, publish assets, change payout readiness, or affect orders are idempotent, so a retried request never produces a duplicate commitment. Audit events are emitted for interest reservations, payment verification and pre-orders, designer and listing-owner payout readiness, payout release, orders, generation, publish, support, privacy, and admin actions. Architecture documents stay short enough to be maintained by a small team; the deeper implementation detail belongs in code, tests, and the Architecture choices page. Until the native phase opens, mandatory architecture validation uses Web and Progressive Web App on desktop plus mobile-width browser smoke, and universal compatibility is preserved by avoiding production code that depends on web-only APIs outside the platform adapter layer.