This page describes the current operating discipline of the DomiDo project: the product decisions that are locked in, the scope items that have been explicitly cut, the top operating risks and their countermoves, the rules that govern change, the signals that would trigger a kill or pivot, and the plan for the first customers. DomiDo is built by Avvyland Limited (UK) and sells universal blocks and fasteners only; every construction shown on the platform is a user-generated design. The underlying decision principle is unambiguous: if a change does not help a real user create, publish, reserve interest, get support, or help the founder learn before the Phase A public beta gate, it waits. The founder and chief technology officer (CTO) can approve scope changes immediately, but every addition has to remove or shrink another task on the same day, and no meeting is required to cut scope — the decision goes into the active operations log, the backlog is updated, and the team keeps shipping.
A small set of product decisions is locked, and these are the choices that shape every other operational decision. Phase A is a public interest beta rather than a pre-order launch, because it is the fastest route to public learning with lower legal and payment friction; the only thing that reopens that decision is an explicit reopening by the founder or CTO. The web Progressive Web App ships first from a universal React Native architecture, which is the fastest route to users while preserving the iOS and Android path, and which is revisited only after Phase A evidence and a native delivery decision. Users and designers own their design outputs because DomiDo is a platform and a manufacturing-enablement system, not the aesthetic owner; that decision never moves without an explicit legal and product decision. DomiDo receives only the limited licences it needs to host, process, translate, moderate, display, validate, and eventually manufacture eligible designs, and that surface only changes alongside a terms update or a new commercial model.
The Phase A public gallery uses user-owned listings because supply and demand can be tested before a designer marketplace is fully monetised; the only condition that reopens it is moderation or intellectual-property risk overwhelming the team's capacity. The Phase A demand signal is the non-binding interest reservation, which removes card friction and legal pre-order drag while proving intent, and which is revisited only when the Phase A.5 readiness gates pass. Phase A.5 itself uses gated Stripe SetupIntent no-capture pre-orders, converting only selected and eligible demand into stronger commitment without charging, and gives way to Phase B fulfilment when its capture readiness lands. Phase A.5 physical pre-order conversion is United Kingdom only to avoid multi-market goods complexity at this stage. Mode A is a must-have because it is the technical wedge; the only reason to reopen it is a complete failure of any real sample to process before beta. Mode B may be controlled or manual in beta, because it is better to collect demand honestly than to fake full automation, and it is revisited when provider quality and cost become reliable. Paid AI design credits stay disabled unless their tax, refund-and-cancellation, and consumer-law gates pass, which is not launch-critical. Phase B fulfilment sits outside Phase A and Phase A.5 entirely because no manufacturing or shipping promises are made before readiness; the gate from Phase A.5 evidence to Phase B fulfilment moves only when the relevant proofs are produced.
A second list, just as important, makes explicit what is not in scope. These are not hidden Phase A tasks that have been forgotten; they have been removed deliberately because they do not earn their cost during beta. A formal change-control board, a role-and-responsibility matrix, a risks-actions-issues-decisions pack, and approval ceremonies are out because they have no direct beta value. Native iOS and Android store releases are out because Web/PWA is enough to acquire beta users now, and App Store and Play Store billing are correspondingly out because native is out and paid AI design credits are conditional. The Phase A card-verification and SetupIntent checkout flow is superseded by non-binding interest reservations and so is itself out. Calling Phase A demand an order, pre-order, purchase, or commitment is out because it misleads users and creates avoidable legal risk. A DomiDo-owned hero-product catalogue as the core launch proof is out because launch proof is user-owned public designs and demand. DomiDo ownership or authorship of user designs is out because it violates the platform posture. Phase B payment capture and fulfilment is out because demand must be proven first. Third-party-logistics order creation and tracking is out because no physical shipment occurs in Phase A or A.5. Designer payout release is out because it belongs in Phase B after captured eligible delivery events, and advanced royalty accounting is out for the same reason; Phase A.5 may show only projected entitlement after terms.
An advanced social graph is out because it is nice later but not needed for reservation validation, a heavy moderation suite is out because a report action and founder triage are enough for beta, and advanced discounts, loyalty, and a referral engine are out because they are not needed before the first real funnel data exists. A full business-intelligence warehouse is out because the founder dashboard, the analytics provider, and exports are enough. A multi-market goods launch is out because UK physical conversion has to come first. A polished assembly companion for shipped kits is out because no kits ship in Phase A or A.5.
The risk catalogue below is not exhaustive — the full risk surface lives on the Risk analysis page — but it is the list of active risks that the operating team watches week to week, each with a severity, a trigger that would escalate it, a named owner, and the countermove that has already been agreed.
| Risk | Severity | Trigger | Owner | Countermove |
|---|---|---|---|---|
| Users believe an interest reservation is legally binding. | Critical | Support questions or UI copy confusion. | Growth / Ops | Rename and fix copy immediately. Add an explicit acknowledgement. Remove all pre-order and order wording from Phase A. |
| DomiDo appears to own or author user designs. | Critical | A listing, badge, or legal copy implies DomiDo ownership. | Founder / CTO | Rewrite copy, terms, badges, metadata, and public pages. |
| Public user-generated content creates an intellectual-property or moderation issue. | High | Reports or similarity concerns appear. | Founder / CTO | Takedown and report workflow, founder triage, block Phase A.5 conversion until resolved. |
| The Mode A pipeline does not process real uploads reliably. | Critical | The sample corpus fails before Gate A3. | Pipeline owner | Narrow accepted formats, add clearer errors, manually process high-intent samples. |
| Mode B output is too weak. | High | Generated drafts are not credible. | Founder / CTO | Launch a controlled generation queue with honest beta timing. |
| Reservations are spammy or low intent. | High | Many fake or duplicate reservations. | Founder / CTO | Tighten authentication and session handling, add rate limits, optional verification, admin qualification. |
| Users browse but do not reserve interest. | High | Listing views are high but reservations are low. | Founder / CTO | Improve offer, trust, owner attribution, price guidance, and listing quality. |
| The founder cannot see failures. | High | The admin dashboard is absent before launch. | Founder / CTO | Build the minimal dashboard before polish. |
| The mobile funnel breaks. | High | The 390-pixel smoke fails. | Frontend owner | Cut advanced UI and fix the gallery, listing, and reservation path. |
| SetupIntent accidentally becomes available in Phase A. | Critical | The payment UI appears before Phase A.5 gates. | Founder / CTO | Disable the feature flag, add a route guard, smoke test. |
| Phase A.5 converts without fresh buyer consent. | Critical | The admin or webhook creates a pre-order automatically. | Founder / CTO | Block conversion. Require buyer action and an audit trail. |
| Legal or tax blocks paid AI design credits. | Medium | Stripe Tax or consumer copy is not ready. | Founder / CTO | Use free beta credits and keep paid credits disabled. |
| Uploads create security exposure. | High | Unbounded files or a public artefact leak. | Pipeline owner | Enforce size and type limits, private storage, authentication, signed references. |
| Team overload causes unfinished surfaces. | High | More than ten open priority-one launch tasks before final rehearsal. | Founder / CTO | Cut the lowest-learning tasks immediately. |
Change control is deliberately compact because a startup cannot afford ceremony. A priority-zero fix is fixed immediately under Founder/CTO authority. A priority-one launch blocker is fixed before any feature work, again under Founder/CTO authority. A reservation or conversion improvement is accepted if it lands the same day and is measurable. UI polish only happens after the checklist is green. A new feature is only accepted if it removes an equal or bigger task from the backlog. A legal or regulatory blocker is either fixed or has its affected feature cut, with advisor input drawn in when judgment is needed. None of these require a meeting; the decision goes into the active operations log, the backlog is updated, and the team keeps shipping.
Kill-and-pivot signals exist to turn learning into a fast decision rather than a long argument. Fewer than fifteen interest reservations in launch week despite 250 or more qualified listing views triggers user interviews and changes to the offer, listing quality, or trust before any new features are built. Fewer than twenty design starts in launch week triggers a simplification of the creation entry and better seeded examples. Fewer than ten published public designs in launch week triggers publish-friction reduction, founder-assisted publishing, and clearer ownership messaging. A reservation cancellation rate above twenty percent triggers an investigation into expectation mismatch, price guidance, trust, or copy. A Mode A success rate below seventy percent on real beta uploads narrows the supported input and guides users to better samples. The same confusion appearing in support five or more times triggers an immediate rewrite of the UI or copy at the point of confusion. Strong Phase A reservations on specific listings prioritise Phase A.5 gates for those listings. A paid-acquisition cost-per-acquisition that looks high before organic proof stops paid spend entirely and returns the team to founder-led outreach.
The first customers come from manual founder effort, not automation. The plan for launch week sets specific behavioural conversation targets across seven channels.
| Channel | Action by launch week | Target |
|---|---|---|
| Existing network | Direct-message homeowners, makers, designers, builders, and garden owners. | 30 conversations |
| Design communities | Share real public designs and ask creators to publish and reserve. | 15 conversations |
| Garden communities | Share eligible free-standing and decorative examples and ask for beta testers. | 10 conversations |
| Landscapers and installers | Ask which kits they would reserve for clients. | 10 conversations |
| Micro-influencers | Offer early access and public-design collaboration. | 5 conversations |
| Local garden centres | Ask for feedback on examples, price, and use-case limits. | 5 conversations |
| Warm beta calls | Watch users use the app live. | 10 calls |
Every conversation has to ask for behaviour — a sign-up, a design start, a publish, a reservation, a referral, or a specific objection — because compliments do not count. The weekly question set keeps the team honest about whether each gate is actually being met: at A2, can a stranger understand DomiDo as a platform for user-owned designs; at A3, can a stranger create or request a design without founder help; at A4, can a stranger publish a valid design and understand ownership and licence; at A5, can a stranger reserve non-binding interest without confusion; at the A7 rehearsal, can a stranger complete the full Phase A funnel on mobile; at 72 hours after the beta starts, did real users show enough intent to justify Phase A.5 conversion work; and at Phase A.5 readiness, are the selected listings legally, technically, and operationally safe to invite to no-capture pre-order.