BREAKING MY APP TO FIX IT
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 an AI assistant for Shopify as development shifts from building to review, debugging, and UI/UX polish. Luqman evolves a command center that separates UI, UX, and backend verification from fix tasks, records outcomes, and supports step-by-step retesting, while routing work among Codex, Claude, and other agents according to the task. Practical work includes migrating the interface to Polaris, reviewing the homepage and report card, and diagnosing classifier, routing, conversation-button, image, live-counter, and relative-date issues. Some cases were verified as fixed, while others remained unresolved, including app slowness, conversation-flow problems, and a vision-analysis failure. Audience discussions cover model and coding-tool selection, voice-chat applications, and local versus cloud model access, with the comparisons treated as informal impressions rather than definitive benchmarks. On product strategy, Luqman argues for examining demand, unit economics, pricing, and customer-acquisition cost before scaling, while acknowledging that pre-validation is not the only path and that currency mismatch and purchasing power can complicate sustainability in some Arab markets.
105 moments from the stream
- 3:09:30
Building a Command Center from a Markdown Specification
Responding to a question about building a command center, the speaker explained that a clear roadmap and a detailed Markdown specification could let a coding agent such as Codex implement much of it. He also described a future plan to demonstrate the build from scratch and share the file.
- 3:12:28
Diagnosing Conversation-Flow Bugs and Retesting
The speaker traces several conversational UX problems, including a confirmation prompt that creates hesitation, a button exposing a user message instead of sending the request internally, and a server-side stream failure. He considers fixing an issue in the same session versus a separate one, then retests and stresses isolating each bug for individual analysis.
- 3:15:33
Subscription Economics in Arab Markets
The speaker argues that users in markets such as Egypt and Algeria may be less accustomed to monthly payments and that purchasing power can make subscription pricing difficult. He says opportunities still exist, but viable unit economics and profitability require careful calculation; this is presented as his view, not a definitive market judgment.
- 3:18:16
Local Service Platforms Versus SaaS
The speaker explains that a transport app adapting an established model to local infrastructure follows a different business model from a SaaS company. Although both involve software, a transport platform depends on marketplace and real-world operations, so it should not be evaluated solely through a SaaS lens.
- 3:23:14
Evaluating a Barber-Booking App Idea
The discussion considers an app where barbers create shop listings, appear on a map, and accept customer appointments. The speaker views it as a promising idea with similarities to a local service platform, but recommends calculating costs and unit economics and confirming a viable profit margin before building it.
- 3:25:19
A Community for Project Feedback and Shared Experience
The speaker describes a chat community where members can share projects, request feedback, and exchange experience gained through practical work.
- 3:28:05
Diagnosing Generic Actions That Do Not Match the Conversation
Luqman observes that a product-catalog data-completeness response always ends with the same generic actions, including rewriting descriptions, even though they do not fit the request. He concludes that routing, verification, and button behavior have a broader problem, then stops the current repair attempt and requests a handoff to another session; this segment does not establish that the issue was fixed.
- 3:29:59
Separating Stress-Test Review from Fix Execution
Luqman reviews the workflow and concludes that the review session was overloaded because it was both evaluating problems and attempting repairs. He describes the Command Center section as a stress-testing area for the UI, UX, and backend, while failed tests and bugs should move into the established execution flow, with an audit that clearly distinguishes testing tasks from fix tasks.
- 3:33:34
Separating review sessions from fix execution
The review area is redefined as a place for testing and recording passes or failures. Discovered problems go into a separate fixes area, are later promoted to task-board work, and return to review for retesting after implementation. An interface check showed that the expected fixes section was not yet visible, prompting a clearer restatement of the requirement.
- 3:41:03
Tracing a classifier crash and retesting it
A classifier test returned zero confidence and was described as crashing completely, sending the conversation to a fallback path even though the server terminal showed no errors. After further debugging and another run, classification returned 0.95 and the speaker said it was fixed, but these pages do not establish a clear root cause.
- 3:49:02
A deferred new-conversation bug
During testing, the speaker noted that the system was expected to open a new conversation but did not. He identified it as a separate bug and deferred it to keep focus on the current debugging work.
- 3:50:34
Separating Exploratory Tests from Fix Tasks
The command center was reorganized as debugging became more difficult. A test meant interacting with the application to investigate UX, UI, or backend behavior, while a discovered problem became a separate fix task. The speaker asked for multiple agents to review the cards, move fixes out of the review section into a dedicated area, and confirm the classification rules before starting.
- 3:53:07
Development Progress and a Historic Launch Target
The speaker said each stream showed new progress, problems, and accomplishments. At the time, the target launch date had shifted from April 17 to April 20 as the work entered a more difficult debugging phase.
- 3:55:04
Feature Check Reveals a Slow UX
A feature described in the captions as “plan enrichment” was tried and appeared to work, but the bot’s slowness remained a clear UX concern.
- 3:56:36
Tracing a Crash That Produced No Reply
The logs showed an analysis step starting and then crashing without returning a reply, providing a clear starting point for tracing the failure.
- 4:00:48
Separating Fixes from Testing in the Debugging Workflow
A dedicated section and milestone were planned for UI/UX review and debugging, with a button that pushes a proposed fix into the task board. The discussion explains that keeping fixes separate from tests reduces confusion when debugging uncovers additional problems, while server logs help track failures and timeouts.
- 4:13:19
Handling a Vision Analysis Failure
Vision analysis failed, so the workflow continued without the vision batch while a Vision API problem was suspected. The captions do not establish the cause or a successful fix.
- 4:14:41
Enriching Fix Tasks Before Execution
The discussion explores enriching fix tasks with more information or a system prompt, noting that products with no images may require a different workflow. A monthly-date issue is used as an example of routing a task into Debug & Review, without establishing a fix in these captions.
- 4:16:15
Replacing Text Confirmations with Buttons
A UX proposal suggests turning approvals such as “go ahead,” “yes,” and “confirm” into explicit buttons while still allowing an operator or merchant to provide approval in text.
- 4:16:44
Execution, Review, and Step-by-Step Test Guidance
The proposed workflow moves a task into in progress and then into review for verification. The agent should not merely complete the task; it should also explain how to test it and inspect the results step by step, with notes raised as a possible addition.
Got a question about something in this stream?
Ask in the group