Context
POCANTRA connects physical NFC cards with editable digital profiles. During a gift activation review in October 2026, I wanted recipients to understand how to claim their card, open their profile and personalize it. Activation already existed. The task was to improve a working journey while preserving the card identities and the ordinary customer flows around it.
The initial brief covered small changes to the activation screen, verification email, success screen and existing-profile editor. Reviewing the journey exposed a more consequential question: when someone presses Save, can we demonstrate that their change actually survives reopening the profile?
Constraint
The existing cards had permanent links. Email verification, token security, profile ownership and paid orders had to remain intact. I required an isolated Preview environment and synthetic QA data so the review could exercise the flow without changing customer records.
The original brief also included a separate complimentary-card ordering feature. That remained outside the completed UX patch. Keeping its status explicit mattered: a polished activation flow could not establish that an additional fulfillment promise had been implemented.
Decision
I defined acceptance around the recipient's actual sequence of actions. The email needed a clear activation button. The success screen needed to offer viewing or personalizing the profile. Editing an existing profile needed to save and return to the owner's profiles, without introducing an unrelated purchase step.
When the mobile review appeared to show an old email, I asked for the received message to be checked: its time, HTML, button and destination. I also required the journey to continue through verification, editing, saving and reopening, with proof that the saved content was visible.
My role was to set those product decisions, protect the environment boundaries and review the experience. The AI coding assistant performed the implementation, diagnosis and technical checks.
Implementation
Hosted QA found a timing defect in the editor. Save could appear available while a background check of the profile URL was still pending. A click during that interval could return without publishing the change.
The assistant made a small fix in the shared editor: while URL validation was pending, Save remained disabled and displayed “Checking profile URL…”. Once validation completed, the first enabled, deliberate click could submit normally. The test deliberately delayed the URL-check response and also checked that entered text survived a failed save.
The evidence for the earlier email concern pointed to different messages grouped under the same subject. The inspected new QA message contained the intended HTML and Preview links. The exact message previously opened on the phone was not independently recorded, so the record retained that uncertainty.
Email authentication was handled separately. Following my explicit approval, conflicting DNS records for the sender domain were removed. The received control message was then inspected for an authentication pass.
Evidence
The saved Preview QA record shows one publish request returning HTTP 200 after the first enabled click, followed by a return to My Profiles. A database readback contained the expected edited headline. A fresh anonymous browser opened the card route and still showed that headline after reload.
I also confirmed that an earlier saved QA profile opened through a link on my phone. That was a mobile-link check; a physical NFC tap of the revised flow was not recorded.
The final email control showed DKIM passing in the recipient's headers, alongside the intended activation button and Preview destination. These checks occurred in separate runs: email and claim, the corrected Save and persistence, and the subsequent email authentication check. A fresh combined run of the whole sequence after the DNS correction was not captured.
Result
At the documented October 8 checkpoint, the UX fix was implemented and verified in Preview. The shared sender-domain DNS correction was applied and verified separately. The application release and complimentary-card ordering remained open at that checkpoint.
The case establishes a specific save defect, its targeted correction and evidence that the edited profile persisted in QA. It makes no claim about a later production release, customer adoption or conversion improvement.
Transferable lesson
For a founder, acceptance criteria should follow the user's intended outcome through the system. A successful screen transition is one observation. Stored data and a fresh reopening provide further evidence.
AI can help inspect the code, reproduce the timing problem and implement the change. The operator still needs to define which outcome matters, protect existing commitments and keep each claim of completion tied to what was actually checked.