Can 150K Emails + Custom Studies Drive Installs?
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 centers on the hardest challenge after building a product: reaching the market and attracting qualified traffic with limited resources. The speaker and audience compare paid ads, inbound marketing, and cold outreach, discussing Shopify-store filtering, email validation, personalized pages, open-and-click measurement, and domain-reputation protection. Viability and ROI remain unresolved; the prevailing direction is to run small staged tests, improve the offer and product before scaling, and avoid treating AI estimates or promised outcomes as proof. Practical work also covers indexing and searching stream transcripts, improving short-form content, and keeping human review in automated publishing workflows. Audience questions range across Codex versus Claude and usage limits, hands-on AI learning, knowledge bases, geographic targeting, and community organization. On product engineering, the discussion emphasizes clear requirements, UX/UI and ERDs, phased delivery, Playwright tests before merge, post-release monitoring, and authentication concerns including login protections, MFA, and SSO. These are presented as evolving discussions, plans, and experiments—not completed implementations or guaranteed successes.
144 moments from the stream
- 5:58:24
Start With UX, Frontend, or Backend?
Participants debate product-development order. One view is that the backend can shape the frontend, and that the right choice depends on the project. Another argues for defining user experience and user flow first, followed by wireframes and a prototype before writing code. Fixing the flow or interface scope early may also reduce feature creep that can arise when starting with the backend.
- 6:03:02
Should Product Development Start with the Backend or UX?
A discussion of competing ways to sequence product development: begin with a backend engine skeleton because core features constitute the product, or begin with user flows and interface design because they reveal backend requirements. A middle path—sketching the engine structure before screens—was also proposed, with the choice qualified as dependent on the individual and the project.
- 6:10:01
Using a No-Code Prototype to Validate an Idea Early
A practical approach was described in which a no-code UI/UX prototype lets a client try the idea before implementation, making early changes easier. The discussion also noted that backend data-fetching choices must align with the frontend because that interaction can affect performance.
- 6:12:45
How Backend Quality Affects the Overall Experience
The discussion suggested that backend problems can undermine the overall user experience, while cautioning that AI advice about development order may be biased or non-objective.
- 6:13:03
From Product Requirements and UX/UI to Software Implementation
Participants discuss a product-development sequence while acknowledging that no ordering is universally correct: establish clear product requirements, shape UX and UI, then align frontend and backend work around the data model, APIs, and implementation. They distinguish UX as the user experience and UI as the user interface, while noting that frontend development is broader than either discipline. Parallel work or vertical slices are presented as ways to connect both sides and reduce rework, with role specialization varying between large companies and smaller full-stack teams.
- 6:25:27
AI as a Full-Stack Implementer
A brief discussion of AI building a backend and aligning the frontend with it, while acknowledging that backend changes may still be necessary.
- 6:26:33
Requiring Approval Before a Coding Agent Starts Work
Questions were raised about why a task and Codex CLI session began without explicit approval, why Codex was chosen, and the unapproved start was acknowledged as a mistake. The discussion also considered whether a command center could replace a product requirements document, while indicating that the setup may need revision.
- 6:30:12
What Is an Entity-Relationship Diagram?
An entity-relationship diagram was described as a visual representation used in software engineering and database design to show relationships among system entities. The discussion then questioned whether one was needed and requested a draft.
- 6:35:12
How PRDs and ERDs Guide AI-Assisted Development
A discussion of documenting product requirements, roles, permissions, data flows, and relationships, then dividing the project into phases beginning with a testable MVP. The speaker argues that locking the documents while retaining change history gives tools such as Codex or Claude more stable context for backend and API work and can reduce cascading revisions as the system grows, while market validation may still lead to revised requirements.
- 6:42:10
Consistent UI Systems in Figma and Guiding the User Journey
A discussion of using Figma to build a design system that keeps inputs, dropdowns, forms, and screens consistent while connecting the visual identity to logos, fonts, and primary, secondary, and accent colors. The speaker explains that button and element placement influences users’ attention and journey through a site, then says the design work may be done in Figma or with a Claude design tool, without establishing that alternatives fully replace Figma.
- 6:44:54
Choosing an AI-Assisted Design Workflow
A discussion comparing, as personal opinions and experiences, design tools and ways to connect Figma with assistants such as Codex or Claude through MCP. The speakers explain that preparing screens before frontend and backend development can expose missing interface elements and workflow steps early.
- 6:47:36
From PRD and ERD to Scalable, Phased Delivery
An explanation of combining a requirements document, database design, and screens with small phases and checkpoints so an AI assistant can implement progressively. The discussion links clear architecture to easier feature changes, API and table-relation decisions, and fewer later performance or resource-cost problems; these are argued benefits, not documented test results.
- 6:51:04
Unit and End-to-End Testing with Playwright
The speakers discuss the limits of relying on AI-generated unit tests, since an assistant may change the test to match its implementation. They present Playwright as a way to run browser-based end-to-end scenarios covering inputs, buttons, navigation, and edge cases, with a suggestion to automate them in GitHub Actions before pull-request review. Details described as a “click script” remained uncertain in the conversation.
- 6:56:11
Playwright Before Merge and Monitoring After Release
The discussion distinguishes automated browser tests that can run with unit tests before a pull request is merged from monitoring tools such as Sentry, which report errors encountered by users after deployment.
- 6:58:11
Breaking Product Development into Phases and Checkpoints
The speaker recommends splitting large flows, such as an authentication cycle, into small phases with explicit checkpoints, then reviewing structure and code stability instead of asking AI to generate a large feature in one pass.
- 7:00:24
Easy-to-Miss Login Security Cases
The discussion covers password-attempt limits, temporary lockouts after repeated failures, and avoiding responses that reveal whether an email is registered, which helps prevent account enumeration. The speaker adds that ongoing security reading and careful AI assistance may cover many known cases, without presenting AI as a complete guarantee.
- 7:02:52
Connecting Coding Agents to Task Boards
The speaker suggests connecting Codex or Claude to boards such as Jira or ClickUp through MCP so they can create and move tasks and track phases or delays. The discussion contrasts that convenience with a preference for a custom Kanban system offering greater control, while noting that open-source alternatives may provide similar integrations.
- 7:07:09
Options for Creating and Exchanging ER Diagrams
The speaker discusses entity-relationship diagrams, including the possibility of using an Obsidian plugin or open-source tools instead of a paid service. He also notes that a JSON representation may be readable by AI-assisted tools and can be rendered as SVG, while some specific tool details remain unclear in the captions.
- 7:12:29
A Healthy Technical Foundation: Design, Testing, and Security
The speaker summarizes advice for building a stronger project foundation to reduce future problems: document data structure with an ERD, understand its place in system design, use Playwright for smoke and end-to-end testing rather than relying only on manual checks, and consider security early in the roadmap. Some referenced security resources are unclear in the captions.
- 7:15:18
Automating Discord as the Community Grows
The speaker says he may build a Discord automation pipeline if the community grows substantially, presenting it as a future plan contingent on that growth.
Got a question about something in this stream?
Ask in the group