This page is the operational checklist that DomiDo uses to decide whether the public beta can open. DomiDo is an AI-assisted modular outdoor construction platform built by Avvyland Limited (UK), and it sells universal blocks and fasteners only; every construction shown on the platform is a user-generated design. The checklist applies first to the public Web/PWA beta of Phase A and then, separately, to the gated no-capture pre-order conversion of Phase A.5 that follows it. The two phases are kept on different tracks throughout: Phase A is about whether strangers can create, publish, browse, reserve non-binding interest, get support, and generate useful product evidence in production, while Phase A.5 is about whether selected reservations can be invited into a Stripe SetupIntent flow without ever charging, shipping, or making a payout claim. Cards, charges, legal pre-orders, invoices, fulfilment promises, and payout claims do not belong to Phase A at all; they belong to Phase A.5 or Phase B after explicit gates have passed.
The Phase A launch is gated by twenty-one hard checks distributed across the production surface, the universal app shell, ownership and trust messaging, the create-and-publish pipeline, the reservation flow, the operating loop, the legal and safety surface, and the release plumbing. Each gate has a named owner — Founder/CTO, Frontend owner, Pipeline owner, Growth/Ops, or the AI pair — and a clear evidence requirement that must be produced before the gate is signed off. The full table below is the canonical list; nothing on it can be silently waived.
| Gate | Owner | Evidence required |
|---|---|---|
| Production deploy | Founder / CTO | Production URL serves the current app and /api/health shows the release version. |
| Universal app shell | Frontend owner | Home, gallery, listing, create, dashboard, and help and support routes load on desktop and mobile-width browsers. |
| Public user-owned gallery | Frontend owner | Seeded and user-published listings load from the API with creator and owner attribution. |
| Ownership and trust copy | Growth / Ops | UI and legal copy state that users own their designs and grant DomiDo the limited processing, display, and manufacturing licence. |
| No DomiDo ownership implication | Founder / CTO | No listing, badge, or hero copy implies DomiDo owns or authored user designs. |
| Mode A | Pipeline owner | A real sample upload creates a processed draft or a clearly described controlled beta state and can publish if valid. |
| Mode B | Pipeline owner | A prompt or reference creates a generated or controlled beta draft with clear timing and state. |
| Publishing | Founder / CTO | Publishing a draft persists visibility, metadata, licence acknowledgement, moderation state, and the safety and use-case gate. |
| Interest reservation | Founder / CTO | A user can create and cancel a non-binding reservation without any card or payment flow. |
| Reservation disclaimer | Growth / Ops | The call-to-action and confirmation clearly say no charge, no order, no pre-order, and no fulfilment promise. |
| User dashboard | Frontend owner | A user sees drafts, listings, saved items, interest reservations, support, and notifications. |
| Founder dashboard | Founder / CTO | Funnel, users, listings, reservations, cancellations, jobs, failures, support, feedback, and alerts are visible. |
| Analytics | Founder / CTO | The event dictionary is served. Sign-up, listing view, create start, publish, reservation create and cancel, support, and feedback events are visible. |
| Support and reporting | Growth / Ops | A user can contact support and report a listing or content. The founder can triage and reply. |
| Beta feedback | Founder / CTO | Feedback stores screen, context, severity, and release, and appears in the founder dashboard. |
| Alerts and incidents | Founder / CTO | One smoke alert creates or updates an incident with owner, severity, trigger, and runbook or action summary. |
| Upload safety | Pipeline owner | File size and type limits, private storage, invalid-file errors, and expensive-work limits are tested. |
| Legal minimum | Growth / Ops | Privacy, terms, cookies, user-generated content licence, interest-reservation disclaimer, product safety boundaries, and support copy are live. |
| Secrets | Founder / CTO | No production secrets are committed. Environment variables load from a secret manager. |
| Browser quality assurance | AI pair | Chrome, Safari, 390-pixel, and 430-pixel smokes are completed. |
| Rollback and flags | Founder / CTO | Risky features can be disabled without redeploying. The production rollback path is tested. |
A second list, equally hard, lists the conditions that automatically block the launch even if every gate above looks green. Any one of them stops the public beta. The presence of a card-details prompt on a Phase A reservation is a no-go because Phase A demand is by definition non-binding and payment-free. Calling a Phase A reservation an order, pre-order, purchase, or commitment in the UI is a no-go because it misleads users and creates avoidable legal and commercial risk. Any implication that DomiDo owns, authored, or sells user-created aesthetics is a no-go because it violates the platform-and-user-owned-design posture. A listing without a report or support path is a no-go because public user-generated content cannot operate safely without one. A reservation that the user cannot cancel is a no-go because it is a trust-and-consent problem. The founder being unable to see reservations or failed jobs is a no-go because the beta cannot then be operated manually. A blocked mobile creation, listing, or reservation path is a no-go because the primary beta audience fails before intent is captured. Private drafts, media, or support data that are visible without authentication are a security no-go. Logs or analytics that expose raw payment, support, private media, or sensitive user content are a data-boundary no-go. Product copy that promises shipment, safety certification, structural suitability, or fixed fulfilment dates is a no-go because Phase A does not support those claims.
The Phase A smoke-test script is a sequence of twenty-one named tests that exercise the production surface in the order a real user would meet it. The script is the canonical proof that the gates above hold up live; each test has a stable identifier so it can be referenced from incidents and evidence packs.
| ID | Test | Expected result |
|---|---|---|
| S-A-01 | Open the production home page. | The page loads, the release is visible through health and configuration, and there is no blocking console error. |
| S-A-02 | Browse the gallery. | Listings load from the API with owner attribution. |
| S-A-03 | Open a listing. | Media, title, owner, localised and fallback copy, save, share, report, and the interest call-to-action are visible. |
| S-A-04 | Search and filter the gallery. | Results update without crashing. |
| S-A-05 | Start Mode A. | The upload UI opens and requires authentication or a session when needed. |
| S-A-06 | Upload a valid sample. | A draft or job is created. |
| S-A-07 | Upload an invalid sample. | A helpful error appears and no expensive job starts. |
| S-A-08 | Process a Mode A sample. | The draft reaches a success state or a clearly described beta failure state. |
| S-A-09 | Start Mode B. | The prompt creates a draft or job or a queued controlled beta result. |
| S-A-10 | Save a draft. | A refresh keeps the draft. |
| S-A-11 | Publish a listing. | The listing appears in the gallery with an owner and a report path. |
| S-A-12 | Reserve interest. | The user confirms a non-binding acknowledgement and no payment UI appears. |
| S-A-13 | Cancel a reservation. | The status changes in the dashboard and admin demand view. |
| S-A-14 | Submit a support request. | The founder can see it and respond. |
| S-A-15 | Report a listing. | The report appears in the admin or support queue. |
| S-A-16 | Check analytics. | Critical events appear with source attribution and consent state. |
| S-A-17 | Submit beta feedback. | The founder dashboard shows feedback with screen, context, and severity. |
| S-A-18 | Trigger an alert smoke. | An incident or alert state appears with owner and runbook summary. |
| S-A-19 | Check data boundaries. | Analytics and logs contain no raw support, payment, or private media content. |
| S-A-20 | Mobile path. | Gallery, then listing, then reserve interest works at a 390-pixel width. |
| S-A-21 | Rollback and flags. | Publishing, interest reservations, or Mode B can be disabled safely. |
Phase A.5 is not automatic; it starts only for selected reservations and listings after a distinct second set of gates passes. The owning designer must have accepted the current design-owner terms and the manufacturing or display licence before any of their listings can be invited. The buyer must explicitly accept the conversion from interest reservation to no-capture pre-order with fresh consent — a previously placed reservation is not enough. The listing must carry no unresolved report, similarity or intellectual-property concern, or prohibited-content flag, and its intended use, category, geography, material or process, and safety claims must be eligible under the product and regulatory boundaries DomiDo operates within. The buyer-facing pricing surface must show the expected price snapshot, currency, tax assumptions, and the non-final caveats that come with a pre-capture flow. Stripe setup must use SetupIntent with Stripe Elements or hosted UI, the strong customer authentication path, both test and live configuration, and idempotency keys, and the webhook handler must be proven idempotent so that a duplicate delivery cannot duplicate the pre-order or change its state incorrectly. The buyer must be able to cancel before Phase B conversion or any capture, and both the buyer and the founder must be able to see the pre-order, its source reservation, the gate versions, and the cancellation state. Throughout the UI, the copy must state clearly that there is no charge now and no fulfilment promise, and that a later Phase B confirmation is required before capture.
The no-go conditions for Phase A.5 are tighter still and any one of them blocks conversion. A reservation that converts to a pre-order without fresh buyer action is a consent problem. SetupIntent availability for unqualified public listings is a marketplace-and-control risk. A SetupIntent success that creates an order, invoice, receipt, shipment, payout, or capture is a violation of the no-capture guarantee. A designer or listing owner who has not accepted the current terms leaves DomiDo without an explicit licence and commercial basis. An unresolved moderation, intellectual-property, or regulatory blocker on the listing is a legal-and-trust risk. Webhook handling that is not idempotent allows duplicate provider events to corrupt payment state.
On launch day, five roles sit in the same operating room with specific screens open all day and a single owned action for each. The Founder/CTO keeps the founder dashboard, deploy logs, error tracker, analytics, and admin reservations open and is responsible for fixing blockers, deciding cuts, and contacting high-intent users. The Frontend owner keeps the browser-and-device test matrix and the frontend error feed open and patches UI and mobile issues. The Pipeline owner keeps the job queue, processing logs, and artefact storage open and retries failed jobs and tunes error messages. Growth/Ops keeps the outreach tracker, inbox, support queue, and analytics open and invites users, responds fast, and records objections. The AI pair keeps the test runner, logs, and issue list open and produces patches, triages regressions, and summarises patterns.
The first 72 hours run on a fixed cadence. Day 0 evening records sign-ups, design starts, published listings, listing views, reservations, cancellations, and blockers. Day 1 morning fixes the top three user-blocking issues before any new feature work begins. Day 1 afternoon messages users who created or published but did not reserve interest, or who viewed high-intent listings, to find out what stopped them. Day 2 improves the highest drop-off point in the funnel. Day 3 makes a single decision: increase outreach, narrow the ideal customer profile, change the offer, or start preparing the Phase A.5 conversion gates.
Every Phase A launch closes with the same evidence pack so anyone can verify the gates after the fact: the release tag, the production URL, the Phase A smoke result, the analytics screenshot or export, the founder-dashboard screenshot or export, the reservation create-and-cancel proof, the support-reply proof, the beta-feedback export or screenshot, the alert-and-incident smoke proof, the log-redaction and data-boundary proof, the open blocker list, and the launch-day metric snapshot. The Phase A.5 payment proof is added to the pack only when the platform enters Phase A.5.