A working storefront with an explicit launch boundary.
Catalog, product pages, cart, and private prelaunch signup—without an unverified order flow.
RECORD THROUGH SEPTEMBER 7, 2026
Recorded INKRALLY storefront homepage
01 / THE QUESTION
What can a visitor actually do while the commerce system is still being validated?
A custom React storefront was built around collections and product pages, then expanded with matching photography. As viewers began arriving, Ethan chose optional launch reminders while keeping payments closed. The resulting flow has to represent that state consistently from entry through the final step.
WHAT THE WORK SHOWED
The live store supports browsing and a cart. A clearly labeled prelaunch flow can save an opted-in email and bag privately. Payments and fulfillment remain paused.
02 / THE METHOD
The decisions behind the output.
01
Make product data reusable
Selected product records drive collection discovery, detail pages, image galleries, and structured product data. Static rendering makes those pages readable in the initial HTML. A product-specific image map keeps the gallery tied to the correct work.
02
Make consent a real branch
Before data entry, the checkout states that orders are not open. An unchecked choice governs whether contact details and the selected bag are saved. Without consent, no contact data is transmitted or stored by that flow.
03
Verify storage and removal
The prelaunch API validates allowed product selections and stores opted-in records privately. The removal flow deletes the contact record while allowing the local bag to remain. The final payment step stays unavailable.
03 / TECHNICAL NOTES
How the parts fit together.
Client behavior and server behavior are separate checks
A success message is only meaningful if the requested record was committed. The release verification read back the saved consent and selected bag, checked that direct public access was blocked, and verified removal.
A failed request cannot look successful
Save errors are presented to the visitor, with retry or continuation without signup. The application does not create an order or request payment as a side effect of saving a bag.
Two audiences, two purposes
Store launch reminders are distinct from Ethan’s newsletter. The lab watcher count measures followers of this experiment, not store customers or purchase intent.
04 / THE REVISION
Where the approach changed.
BEFORE
A polished shopping interface existed before the commerce-to-fulfillment path was verified.
AFTER
Visitors can browse and optionally save their interest, with consent, error handling, and removal behavior checked.
The decision: Ethan kept payments paused and chose an explicit prelaunch reminder option.
ETHAN / DIRECTION & REVIEW
Ethan set the commercial boundary: remain closed for payments while allowing optional launch reminders.
GPT-6 + TOOLS / EXECUTION
GPT-6 wrote the React storefront, catalog integration, server validation, private storage flow, and browser verification.
05 / EVIDENCE & LIMITS
What supports the claim.
Live release verification
The September 7 audit recorded saved consent and bag data, blocked public record access, unavailable payment, and successful removal.
Cleanup verified
The temporary verification record was removed. No email, payment, or order was created during the check.
Limit
This verifies the prelaunch flow, not a completed purchase. Paid checkout, fulfillment, and order communication still require end-to-end validation.
Based on retained project records and selected public artifacts. Historical checks describe the recorded release; they are not continuous monitoring or an independent audit.
THE NEXT CHECKPOINT
Complete the remaining commerce setup and a verified owner test order before opening customer payments.