Working on Merchant Facing UI
Want to back the stream? The «داعم» membership on YouTube is EGP 60 a month: badges, emoji, and I answer your questions first on stream. Become a supporter
The gist
The stream follows preparations for a Shopify app submission, prioritizing completion of the move from Polaris React to Polaris Web Components and visual and functional QA of the merchant interface before returning to website, report, and funnel polish. Practical work also covered GA4, Google Tag Manager, and PostHog configuration; verifying that changes reached production through GitHub and Cloudflare; reviewing Supabase table organization; and troubleshooting MCP access—without treating visible identifiers alone as proof of end-to-end tracking. Luqman drew lessons from accumulated Git branches and worktrees and from coding-agent completion claims that failed manual inspection, arguing for regular integration and direct verification. He also discussed automated build-and-audit agent loops, his personal impressions of Codex and Claude, and audience questions about deployment, model choice, project languages, client acquisition, programmatic SEO, Kanban boards, and Hermes. Open questions remained around some Cloudflare and MCP failures, the best database organization, the value of particular agent tools, and the final submission date.
104 moments from the stream
- 0:00:30
Risks of Git Branch Cleanup and Parallel Agent Work
The speaker describes how asking an AI agent to clean up overlapping Git branches and worktrees led to an unwanted merge and loss of recent work, requiring block-by-block recovery. He concludes that reducing parallel branches may avoid conflicts when multiple sessions touch the same areas.
- 0:06:58
Using an Early Funnel to Validate Customer Interest
The speaker outlines a funnel that begins with an AI visibility audit and then offers an early-cohort option. He treats early commitment as a possible signal of strong interest, while stressing that the cohort is not yet certain and a later phase will test market demand over several weeks.
- 0:07:54
Why Task Lists Expand During Product Development
The speaker explains that task count is not a fixed measure of progress: as product requirements become clearer, new work emerges and the list may grow despite substantial completion. Nearer the finish, remaining steps become more specific, though the final scope remains uncertain.
- 0:08:41
Completing the Move to Polaris Web Components
The speaker says the app began with React Polaris and was later moved toward Polaris Web Components after he discovered a Shopify recommendation that he dates to October 2025. Because part of the migration was incomplete, he created a milestone to review the UI and standardize the app on the newer components before continuing go-to-market preparation, with planned assistance from Claude and Codex.
- 0:10:23
Balancing Launch Speed with Product Readiness
A progress update on successfully merging branches and temporarily postponing website polish to focus on the application. The submission date remains uncertain because it depends on the remaining engineering work and the aim of delivering something market-ready.
- 0:12:20
Preparing and Executing a Milestone with Coding Agents
An explanation of a workflow where agents inspect a task and codebase and produce a detailed prompt for a builder agent. The plan is to prepare the tasks in advance and attempt the milestone through one automated command; completion was not demonstrated here.
- 0:14:21
Reviewing Supabase Changes and Remaining Work
A review of a Supabase database after tables were added and work was done around refund and payment flows, followed by a request for clearer details about what a specific task implemented and what still needs verification in the database.
- 0:16:37
Streamlining CRM and Go-to-Market Workflows
Notes on the need for a structured CRM flow and fewer excessive tasks in GTM work, with interest in seeing whether the strategy can generate traction and user cohorts before considering broader sharing.
- 0:17:27
Connecting Obsidian with Coding Tools While Managing Usage Limits
A proposed approach for using Obsidian vaults with coding tools, based on a workflow seen online. Implementation was deferred, with work to be balanced between Claude and Codex because of usage limits.
- 0:19:00
Distinguishing Prisma Tables from the Tables Visible in Supabase
An attempt to understand why the expected tables were not visible in Supabase, including how to access Prisma tables and how they differ from the other tables shown. The question was not resolved on this page.
- 0:20:22
Coding-tool usage limits and data-center pressure
The speaker says weekly usage limits seemed to run out quickly despite efforts to conserve tokens, possibly because of workload and data-center pressure after users moved to Codex. This was presented as a hypothesis, not a confirmed cause.
- 0:23:25
Checking Supabase MCP connectivity
A troubleshooting step checks whether the Supabase MCP server is active and available to the current session.
- 0:24:52
Risks of accumulating branches and Git worktrees
The speaker describes how unchecked branches, Git worktrees, pull requests, and backup files accumulated without regular merging, confusing the coding agent; an attempt to use multiple agents to merge the backlog made matters worse. It is framed as a personal experience and a warning about unmanaged parallel work.
- 0:26:00
Separating migration work from UI debugging
The workflow plan is to finish ongoing migration work in one session, then open another session dedicated to inspecting and debugging the application UI, without claiming the next step is guaranteed to succeed.
- 0:26:49
Partially automating short-form content publishing
The speaker says short-form posts and reels had paused amid distraction. The workflow was partly automated but still required burdensome manual steps, while content creation remained an important recurring part of the work.
- 0:27:29
Moving work to a Codex session with MCP access
After finding that the current session lacked the expected Supabase MCP access, the speaker planned to open a new Codex session where it was available and requested a concise context handoff.
- 0:28:23
A conditional timeline for phase one and app submission
The speaker could not give an exact date for the first go-to-market phase, saying timing depended on product-related work after the website and payment infrastructure were completed. At the time of the recording, the goal was to submit the application the following week and likely before May 26, explicitly as an estimate rather than a firm promise.
- 0:30:06
Balancing MVP Quality with Shipping Speed
The speaker argues that a first release should deliver real value and meet a solid standard without letting perfectionism delay launch. Additional polish can follow in later versions once usage signals appear, though he acknowledges that this balance is difficult.
- 0:34:35
The Cost of Branch and Worktree Complexity Before Launch
The speaker questions the overhead of accumulating branches, worktrees, and repeated commit requests during a pre-launch phase. In his view, that degree of isolation becomes more valuable when changes can affect a live application.
- 0:40:22
Reviewing Database Schema Sprawl
The review reveals a large set of database tables that has become difficult to track, with some possibly introduced during agent-driven work without immediate notice. The practical takeaway is to audit and clean the schema while confirming what each table is for.
Got a question about something in this stream?
Ask in the group