Eight image directions.

The audience is a designer who can make screens but does not yet understand the technical systems needed to make a product work. They may have a technical degree, but GitHub, hosting, databases, permissions, APIs, agent instructions, and the current AI tool ecosystem may still be unfamiliar.

The promise: I help designers turn their ideas into working products, and explain the decisions and connections along the way.

Viewers should eventually be able to describe their idea, research a real need, select a manageable set of tools, organise a project, save versions, build a usable interface, connect data and services, publish it, and keep improving it. This gives the series a concrete outcome beyond learning prompts.

Dhrumil's preferences:

• No face on camera; own voice is welcome.
• Show skills, working products, creative experiments, and practical processes.
• Use Claude and Codex prominently without making every lesson a tool comparison.
• Teach enough technical understanding that viewers can make informed choices.
• Alternate sequential lessons with own-product/tool posts and general design/research stories.
• Build visibility and an audience; no selling now.

Official documentation and a small sample of community questions suggest a useful editorial emphasis:

Community discovery also surfaced questions about deployment and managing a codebase without technical knowledge: nontechnical codebase discussion. This is anecdotal topic discovery, not a representative audience survey or a source for technical instructions. The conclusion that these are useful content gaps is an editorial inference, reinforced by Dhrumil's explicit audience description.

Existing content worth studying for its teaching structure

I reviewed these public pages for editorial structure. This does not assess the quality of a paid course or endorse every technical claim on the page. Use official documentation for current setup, model, billing, and access details.

These examples show that beginner product-building content already exists. Your proposed distinction is the combination of your own design/build evidence, clearly explained connections across tools, a sequential product, and alternating design stories. That is an editorial positioning choice, not a claim of an uncontested niche.

Use a four-post cycle:

Repeat 15 times: 30 series lessons + 15 explorations + 15 design stories = 60 primary posts. Reusing a post on another platform does not count as another lesson.

At one post per day, the season spans 60 days. If it is five posts per week, it spans 12 weeks. Use episode numbers rather than calling alternate-day lessons consecutive days.

Recommended title: From designer to product: 30 lessons with Claude + Codex. Possible subtitle: Plan it, design it, connect it, publish it.

If you want a strict 30-calendar-day opening, publish the first 15 sequential lessons and their 15 companions in that month, then continue the season. Do not pretend the whole foundation is finished halfway through.

Suggested capstone: Design Shelf, a small inspiration library for designers. This is a proposed teaching example, not a new build authorised by this task.

Core user task: save a reference with a source link and a short note, organise it, and retrieve it for a design decision.

Start with saving a link and note. Add tags, persistent data, sign-in, images, and one optional AI-assisted feature progressively. A useful AI feature could suggest tags for a note; make suggestions reviewable. The product should work without that paid feature.

Why this fits you:

• Inspiration, design memory, and reference selection are familiar design tasks.
• It gives data, permissions, APIs, and interface states a visible purpose.
• Use a fictional inspiration-memory example that viewers can recreate.
• It is small enough to teach progressively.
• It provides a coherent example while other posts show your wider range.

Version-one scope: owner sign-in, reference list, add-reference form, tags/search, edit/archive behaviour, and persistent notes. Media and AI enhancements can be optional branches. No social network, payment system, multiplayer editing, or mobile app in the initial scope.

The system viewers should understand:

Research + references + project documents
                    |
                    v
Claude Code or Codex works on your local project
                    |
                    v
Git saves versions -> GitHub stores and shares the repository
                    |
                    v
Hosting serves the interface and any backend functions
          |                      |
          v                      v
Database + access rules    Server calls external APIs
          |                      |
          v                      v
Saved notes and users      AI results or other services

File storage holds uploaded/generated media.
Your browser displays the interface and requests permitted actions.

The diagram describes one route. Providers and connection methods can differ. GitHub is not the database; database access rules do not come from the visibility of a repository.

For the viewer, teach one primary route and one alternative at relevant decision points. Dhrumil can demonstrate both tools from his own setup; viewers do not have to buy both.

Cost lesson: record the date and distinguish the bill

Prices checked on 8 October 2026, USD, before taxes and local checkout differences:

• ChatGPT Plus is listed at $20/month in official Codex pricing. Included usage has limits; API-key usage follows API pricing.
• Claude Pro is listed at $20 when billed monthly, with an annual alternative on the Claude pricing page. Its Claude Code access guide explains subscription access and API-key billing behaviour.
• GitHub Free is $0 and supports public/private repositories: GitHub pricing.
• Cloudflare Workers has a Free plan and a Paid plan with a $5/month minimum plus applicable usage: Workers pricing.
• Supabase has a Free plan; Pro is listed at $25/month with compute/usage considerations: Supabase pricing.

A learner choosing one $20 builder and remaining within relevant free infrastructure quotas could begin with that subscription cost. This is an illustrative starting budget, not a guaranteed all-in bill. Domains, paid APIs, media generation, add-ons, overages, taxes, and production needs are additional considerations.

Explain four spending categories: the tool you use to build, infrastructure that runs the app, services the app calls, and optional creative production. A plan that lets you use a model in a desktop app does not automatically give your public app unlimited model calls. Some plans include API credits or allowances; check their terms rather than making a blanket claim that every allowance is interchangeable.

Each brief below is an editorial specification. Actual click-by-click instructions must be recorded against a working project and current app version before publication. Include prerequisites, a visible result, a verification step, and a recovery path in the companion guide.

Episode 01: What actually makes a product work?

• Hook: “Your design is one part of the product. Here is what connects to it.”
• Teach: interface, backend, data, files, accounts, external services, hosting; website versus app versus prototype.
• Demonstration: follow one action, saving a reference, through the proposed system; show where each part lives.
• Viewer output: a one-page map of their own idea, with unnecessary services crossed out.
• Check: can they name where the interface runs, where data lives, and whether other people can access it?
• Recovery topic: do not start with a large stack; identify the next missing capability.

Episode 02: Which accounts and plans do you need?

• Hook: “Here is what you need to start, and when another subscription becomes useful.”
• Teach: app subscription, usage limits, API billing, hosting quotas, database quotas, domains; browser chat versus coding agent.
• Demonstration: date-labelled plan comparison, intended usage, and a starter cost sheet. Hide billing identity and credentials.
• Viewer output: chosen builder, GitHub account, planned host and data route, monthly budget.
• Check: one tool for each actual need; viewer understands which service bills for a generated result inside their app.
• Recovery topic: when usage runs out, compare waiting, simplifying the task, and a deliberate upgrade.

Episode 03: Your workspace, files, and local preview

• Hook: “Where does the product live before it is online?”
• Teach: project folder, file extensions, editor, terminal, runtime, packages, local server, localhost.
• Demonstration: open the correct folder, identify the entry files, start the documented preview, stop it, and reopen it.
• Viewer output: a named project folder and working local preview from a small starter.
• Check: the viewer can distinguish the editor, terminal, and browser and locate their files.
• Recovery topic: wrong folder, missing dependency, or a port already in use. Explain what a command does before running it.

Episode 04: Choose a problem and keep the first version small

• Hook: “A buildable first version starts with one useful job.”
• Teach: audience, current workaround, evidence, assumptions, user task, minimum version, exclusions.
• Demonstration: compare an overlarge feature list with the save-and-find-reference task; use real observations where available.
• Viewer output: a product brief with one main task, three core capabilities, and open research questions.
• Check: every initial feature supports the chosen task; assumptions are labelled.
• Recovery topic: turn unknowns into questions instead of letting AI invent answers.

Episode 05: Take inspiration with a reason

• Hook: “What exactly are you borrowing from this reference?”
• Teach: interaction references, visual references, content hierarchy, context, source attribution, originality.
• Demonstration: annotate a small reference set; choose a principle from each and show how it changes in your product.
• Viewer output: references.md or a reference board with source, useful principle, and intended application.
• Check: explain the use of each reference without “it looks nice”.
• Recovery topic: incompatible references, copied surface styles, or references that solve a different user task.

Episode 06: The Markdown files that organise your project

• Hook: “These text files help you and the agent work from the same understanding.”
• Teach: .md formatting, project brief, README, PRD, design rules, decisions, tool-specific instructions.
• Demonstration: create a few short files and explicitly ask the agent to read the relevant ones before a task.
• Viewer output: readable project brief, design notes, and agent instructions.
• Check: ask the agent to summarise the current goal and constraints; compare with the files.
• Recovery topic: naming a file does not guarantee automatic loading; eliminate stale or conflicting instructions.

Episode 07: Plans, goals, milestones, and acceptance checks

• Hook: “How do you tell whether the agent has actually finished?”
• Teach: outcome, dependencies, staged work, acceptance checks, progress notes, task scope, review.
• Demonstration: split saving a reference into interface, validation, persistence, permissions, and real-flow checks.
• Viewer output: a small milestone plan with observable completion criteria.
• Check: a milestone can be evaluated by performing an action, not by reading “done” in the chat.
• Recovery topic: a goal feature in an agent is not proof of completion; keep independent evidence and current status.

Episode 08: Git and GitHub, through a visible save

• Hook: “Here is how I save a version I can return to.”
• Teach: Git versus GitHub, repository, tracked file, commit, remote, push/pull, public/private.
• Demonstration: use a visual Git interface to review a small change, name a commit, push, and inspect it online.
• Viewer output: a repository with a meaningful initial commit and documented setup.
• Check: the intended files are present remotely and no secrets or generated clutter were included.
• Recovery topic: a local commit has not reached GitHub until pushed; private source does not make a deployed site private.

Episode 09: Branches, pull requests, and recovering a version

• Hook: “Try a new direction while keeping a working version.”
• Teach: branch, diff, pull request, review, merge, conflict, revert; worktrees as an optional sidebar.
• Demonstration: experiment with a layout on a branch, inspect the difference, compare both results, and demonstrate a bounded revert.
• Viewer output: a reviewed experiment with a known working checkpoint.
• Check: the saved working state remains retrievable.
• Recovery topic: reverting source code does not reverse database changes or recover every uploaded file.

Episode 10: Give the agent useful context and focused tasks

• Hook: “Show the agent what matters before asking for a change.”
• Teach: input context, screenshot, file reference, constraints, current state, desired outcome, task boundaries.
• Demonstration: compare two bounded requests using the same example; inspect results against the same criteria.
• Viewer output: a useful task request containing evidence and a completion check.
• Check: the requested change is observable and unrelated features remain functional.
• Recovery topic: context drift, vague praise, endless re-prompts, and asking for several unrelated changes at once.

Episode 11: Plugins, connectors, MCP, and APIs

• Hook: “What changes when an AI tool connects to Figma or GitHub?”
• Teach: connector access, read/write permission, a plugin package, a skill workflow, MCP as a tool-connection protocol, API as service access.
• Demonstration: install or enable one needed connection, authenticate it, read a specific source, and confirm the result.
• Viewer output: one working connection plus a note about its access and purpose.
• Check: the agent reads the intended account/file; access is limited to the task.
• Recovery topic: account mismatch, revoked access, unsupported features, and assuming a logo means a connection works.

Episode 12: Make a reusable design skill

• Hook: “Can the next project use the same design review process?”
• Teach: scoped workflow, triggers, instructions, examples, when to load a reference, portability differences.
• Demonstration: write a short design-review skill and apply it to two different examples.
• Viewer output: a small repeatable checklist/workflow with a tested use case.
• Check: the skill improves a specific task and does not load irrelevant instructions everywhere.
• Recovery topic: more instructions can produce more contradiction; a skill is guidance, not a replacement for access or judgment.

Episode 13: Move between Figma, references, and product structure

• Hook: “Which parts of this design need to reach the build?”
• Teach: user flow, information architecture, wireframe, component behaviour, design context, screenshots and exports.
• Demonstration: bring the main task screen into the selected workflow; explain what transfers and what still needs interpretation.
• Viewer output: a clear screen/flow specification with content and states.
• Check: intended behaviour is described; a screenshot is not treated as a complete interaction specification.
• Recovery topic: inaccessible files, missing fonts/assets, or a connector unavailable on the learner's account.

Episode 14: Build the first real interaction

• Hook: “This button will do something you can check.”
• Teach: HTML structure, CSS presentation, JavaScript behaviour, components, framework/package roles at a practical level.
• Demonstration: build reference entry and list display with sample data; inspect one interaction in the browser.
• Viewer output: a usable local interaction with validated input.
• Check: adding a valid item changes the list; invalid input gets useful feedback.
• Recovery topic: a convincing mock screen can still have nonfunctional actions. Name mock data explicitly.

Episode 15: Make it work across states and screen sizes

• Hook: “What happens when the title is long or the screen is narrow?”
• Teach: component consistency, responsive layout, focus, empty/loading/error states, long content, design tokens.
• Demonstration: test realistic awkward content, small screens, and missing data; fix one coherent group of problems.
• Viewer output: a responsive interface with clearly defined states.
• Check: complete the main task on a phone-sized view and using a keyboard.
• Recovery topic: hiding important actions, overflow, unreadable crops, or state changes that move the layout unexpectedly.

Episode 16: Where should the data live?

• Hook: “Will your saved references still exist on another device?”
• Teach: in-memory data, browser storage, cloud database, table, row, column, ID, relationships; database versus files.
• Demonstration: show the same record in an interface and a proposed table; compare local-only behaviour with a cloud-backed goal.
• Viewer output: a small data model for profiles, references, and tags.
• Check: each record has an owner and required fields; viewers can explain refresh and cross-device behaviour.
• Recovery topic: browser storage is not a substitute for cloud sync; a GitHub repository is not a live user database.

Episode 17: Connect a database and verify persistence

• Hook: “Let us prove this form really saves.”
• Teach: database project, connection configuration, basic create/read/update, migrations, sample data, access rules.
• Demonstration: connect the primary data route; restrict this intermediate demo to an owner-controlled test context until the access lesson is complete.
• Viewer output: a test record saved and retrieved from the database.
• Check: verify the record in the provider and after refresh; test invalid data.
• Recovery topic: wrong project URL, mismatched fields, missing configuration, or a policy blocking an operation. Do not solve permission errors by opening all access.

Episode 18: Sign-in and who can access which data

• Hook: “Logging in and owning a record are different checks.”
• Teach: authentication, authorisation, session, owner ID, database policies, public versus secret credentials.
• Demonstration: create two test users; show allowed access and a rejected attempt to access the other's private record.
• Viewer output: working sign-in/out plus owner-scoped data rules.
• Check: two-account isolation, expired-session behaviour, and the logged-out path.
• Recovery topic: hiding an edit button is not a server/database permission rule. Keep provider-specific setup in the follow-along guide.

Episode 19: Files, images, and storage

• Hook: “The image file and its database record live in different places.”
• Teach: storage bucket, object/file, metadata, access, upload validation, file size, private/public URLs.
• Demonstration: upload a permitted sample image, link it to a reference, and explain how the metadata relates to the stored file.
• Viewer output: an owner-controlled upload with a clear preview and error path.
• Check: wrong file type, large file, failed upload, and permissions.
• Recovery topic: temporary media links, mismatched records, orphan files, and exporting data without its assets.

Episode 20: Connect an API and keep the secret on the server

• Hook: “The app can call another service without showing its secret to the browser.”
• Teach: request, response, endpoint, JSON, API key, backend route, environment variable, quota/error response.
• Demonstration: browser requests one operation from your backend; the backend calls a selected provider and returns a controlled result.
• Viewer output: one API feature behind the appropriate server-side boundary.
• Check: no private key in browser output or repository; invalid requests fail clearly.
• Recovery topic: client-exposed environment variables remain visible; not every provider key is a secret, but secret keys require protection.

Episode 21: Add a useful AI feature with waiting and cost controls

• Hook: “What should happen between clicking Generate and seeing the result?”
• Teach: model/service selection, token or unit cost, pending/success/failure states, timeouts, controlled retry; polling versus webhook as an extension.
• Demonstration: suggest tags for a reference, let the owner review them, and show the unavailable-service path.
• Viewer output: one optional AI enhancement with a bounded input/output and usable fallback.
• Check: malformed output, duplicate clicks, provider failure, and actual cost/usage visibility.
• Recovery topic: do not retry forever or promise accurate percentage progress when the provider does not report it.

Episode 22: Publish the product and connect GitHub to hosting

• Hook: “Here is what changes when the product leaves your laptop.”
• Teach: build, deployment, host, repository connection, backend runtime, preview URL, config, secrets.
• Demonstration: deploy the previously checked core to the selected Cloudflare route; identify each required connection.
• Viewer output: a working preview with the correct data/service configuration.
• Check: open in a clean browser, complete sign-in/save/reload, and inspect the actual deployed result.
• Recovery topic: wrong branch, wrong build command, missing environment variables, unsupported runtime, or local-only files.

Episode 23: Domain, DNS, HTTPS, and separate environments

• Hook: “Why does this URL work while your custom domain does not?”
• Teach: domain versus host, subdomain, DNS record, HTTPS, local/preview/production, environment-specific credentials.
• Demonstration: map a sample domain setup and explain which environment each URL reaches. Use an existing controlled demonstration when possible.
• Viewer output: an environment/URL map and an optional configured custom domain.
• Check: intended host and environment, secure loading, correct callback URLs, and no mixed test/real data.
• Recovery topic: propagation is not the explanation for every failure; inspect the actual record and host configuration.

Episode 24: Art-direct useful images and integrate them

• Hook: “The generated image still needs a job in the design.”
• Teach: subject, composition, style references, constraints, iteration, edit versus regenerate, crops, formats, alt text.
• Demonstration: generate or edit a coherent asset, refine it, and place it in the actual interface with the correct crop.
• Viewer output: a small asset set with source/process notes and web-ready exports.
• Check: readability, consistency, dimensions/file size, and whether the interface works without the image.
• Recovery topic: unintended text/details, weak consistency, oversized assets, and images that compete with the task.

Episode 25: Video, web motion, and a reusable animation

• Hook: “Which kind of motion does this product need?”
• Teach: generated footage, edited video, rendered motion graphics, interactive web animation; timeline, easing, export versus interaction.
• Demonstration: one purposeful web animation; contrast it with an authored video/invitation example. Put the full video-generation/render steps in the companion guide.
• Viewer output: one motion treatment with an explained purpose and reduced-motion alternative.
• Check: interaction timing, phone behaviour, loop/pause where relevant, audio choice, and text readability.
• Recovery topic: a video playing inside a page is not an interactive 3D scene; slow animation can delay a task.

Episode 26: A small 3D website experience

• Hook: “What actually makes this object interactive on a website?”
• Teach: scene, camera, lighting, material, object/model, embed versus code implementation, performance/fallback.
• Demonstration: use a small Spline scene on a product/demo page, with an ordinary image fallback. Introduce Three.js as a different level of control.
• Viewer output: one bounded 3D interaction with a reason to exist.
• Check: phone load, touch behaviour, fallback, readability, and whether the essential task is still usable.
• Recovery topic: heavy models, many effects, poor contrast, and a scene that consumes the whole interaction budget.

Episode 27: Test the whole product, including failures

• Hook: “A working homepage is only one check.”
• Teach: manual task check, browser automation, accessibility inspection, performance, two-user isolation, failure modes.
• Demonstration: add/save/find/edit a reference, reopen it, sign out, test another account, and simulate an API failure. Use browser automation for a repeatable critical path where helpful.
• Viewer output: a tested checklist and a small set of meaningful regression checks.
• Check: record what actually ran, expected result, observed result, and unresolved cases.
• Recovery topic: a generated test is useful only if its assertions capture intended behaviour; passing checks do not prove every user need is met.

Episode 28: Debug, recover, and distinguish code from data

• Hook: “Where would you look when this works locally but fails online?”
• Teach: reproduction steps, browser console, network request, build/runtime logs, source revision, deploy rollback, database recovery.
• Demonstration: diagnose one reproducible error, fix it on a branch, check the result, and explain a bounded recovery plan.
• Viewer output: a bug report and verified fix with a known checkpoint.
• Check: reproduce before the fix and confirm the same path afterwards.
• Recovery topic: a code rollback does not undo a schema migration or restore an erased file. Preserve data before changing its structure.

Episode 29: Research, feedback, and a focused second version

• Hook: “What did someone actually struggle with?”
• Teach: realistic task scenarios, observation, consent, note-taking, supported insights, prioritisation, hypotheses.
• Demonstration: use a real permitted session or clearly label the example as a planned test; trace a finding to a revision.
• Viewer output: a short research record and a prioritised revision plan.
• Check: distinguish observed behaviour, participant statements, your interpretation, and unanswered questions.
• Recovery topic: AI-generated users and quotes are not substitutes for evidence from real participants.

Episode 30: Release, document, and keep improving

• Hook: “Here is what is finished, and what running the product still involves.”
• Teach: release checklist, version notes, ownership, monitoring, cost review, backups, exports, support, next milestones.
• Demonstration: full product walkthrough, a fresh-browser check, maintenance notes, and a next-version backlog.
• Viewer output: a shareable product appropriate to its tested scope, README/setup notes, known limitations, and a maintenance plan.
• Check: another person can understand the product, access the intended experience, and recover their work appropriately.
• Recovery topic: do not describe a private demo as a public production launch; keep the claim aligned with the actual release.

Days are relative to your chosen launch date. Core episodes run in dependency order. Exploration and design-story posts are independently understandable and point to a related core lesson when useful.

P06/P09/P10/P11/P14 are proposed demonstrations to prepare, not claims that you have already used or validated every named integration. You can swap a product/tool exploration while retaining the core lesson order.

Use public or cleared examples. Keep confidential work and source archives private.

These extend the season. They are a selection bank, not another daily commitment. Some become companion posts; others belong in later seasons after prerequisites are established.

Planning and research

1. How to turn a vague product idea into one user task.
2. The questions to answer before buying tools.
3. A feature list with a clear first-version boundary.
4. How to label assumptions in a product brief.
5. Desk research versus watching a user perform a task.
6. A competitor table that compares actual workflows.
7. Ask questions without leading the participant.
8. Turn interview notes into supported observations.
9. The smallest experiment that tests a product assumption.
10. Prioritise a feature by evidence and effort.

Inspiration and visual judgment

1. Annotate a reference instead of merely collecting it.
2. Separate visual inspiration from interaction inspiration.
3. Explain which parts of a reference do not fit your context.
4. Combine compatible principles from different references.
5. Make an original variation of your own older screen.
6. Design one task for calm versus urgency.
7. Choose typography by content and reading task.
8. Test a colour system in success/error states.
9. Use your own photograph to build an asset direction.
10. Keep useful source attribution in a reference library.

Project files and context

1. Markdown in five visible formatting examples.
2. README versus product brief versus PRD.
3. What belongs in agent instructions.
4. How to confirm an agent read the intended file.
5. Stale documents that contradict the build.
6. Decision logs that explain why something changed.
7. Session summaries that help you resume work.
8. A changelog written for someone who uses the product.
9. Keeping project guidance short enough to be useful.
10. Tool-specific file-loading differences in your installed versions.

AI tools and extensions

1. Browser chat versus an agent working on local files.
2. A plugin, connector, MCP server, and API compared through one task.
3. Read access versus write access in a connected app.
4. Choosing a plugin because you need a capability.
5. A skill used successfully on two projects.
6. A skill that loads irrelevant instructions and how you fix it.
7. Reproducing one tool comparison with matched inputs.
8. Model/effort selection measured on one specific task.
9. Scheduled tasks, useful triggers, and what they should report.
10. Parallel agent work: when it helps, integration cost, and why one agent may suffice.

Files, Git, and collaboration

1. Local files versus files stored in a remote repository.
2. GitHub Desktop through a visible layout change.
3. What a useful commit message says.
4. A branch for a design alternative.
5. Inspect a diff without reading every line of code.
6. A pull request description tied to visible behaviour.
7. Public code, private code, and public deployments.
8. What .gitignore does and does not undo.
9. A merge conflict explained with two versions of a text file.
10. Recover a known working code version while preserving current work.

Building interfaces

1. HTML, CSS, and JavaScript through one real control.
2. Why a project uses a framework.
3. Packages, package managers, and lockfiles.
4. What localhost and a port mean.
5. A component with explicit behaviour and states.
6. Realistic content as a layout stress test.
7. Responsive reorganisation versus shrinking.
8. An accessible keyboard path through a form.
9. Design tokens used in the actual build.
10. Bring an implemented interface back into editable design context.

Databases and storage

1. A table shown beside the screen that reads it.
2. IDs and relationships in a reference library.
3. Refresh persistence versus cross-device persistence.
4. Browser storage versus database-backed storage.
5. Database records versus image/video files.
6. A schema change and why it needs a migration.
7. Sample data and real data kept separate.
8. D1 versus hosted Postgres for a specific project.
9. Export your notes and preserve media references.
10. Backups and an actual recovery demonstration.

Accounts and permissions

1. Authentication versus authorisation in one example.
2. Two test accounts checking data isolation.
3. Why a hidden button does not protect an action.
4. An owner field and a matching access policy.
5. Sign-in callbacks across local and deployed URLs.
6. Expired sessions and helpful recovery.
7. Publishable keys versus private service credentials.
8. Role-based actions in a small admin interface.
9. Private files and controlled download links.
10. Account/data export and deletion design, with proper confirmation.

APIs and automation

1. A request and response shown as a product action.
2. JSON explained using a reference record.
3. A backend route keeping a provider secret private.
4. Environment configuration across local and preview.
5. CORS explained through a controlled example.
6. Request limits and a useful retry message.
7. Polling versus a webhook for a long task.
8. Prevent duplicate submissions and duplicate spending.
9. Connect email or a calendar using current provider guidance.
10. Build an AI feature that still leaves the user in control.

Creative media and 3D

1. Reference-driven image art direction.
2. Edit a specific image detail without changing the composition.
3. Crop the same asset for desktop and mobile.
4. Image-to-video with controlled camera/motion intent.
5. Storyboard a short product film before generation.
6. A reusable typography video made with code.
7. CSS motion versus a GSAP timeline.
8. Spline embed versus a Three.js implementation.
9. Optimise one 3D scene for a phone.
10. A static/reduced-motion fallback that preserves the message.

Publishing and maintenance

1. GitHub to Cloudflare connection, traced end to end.
2. Choose hosting based on the build's runtime needs.
3. Preview URL versus custom domain.
4. DNS, subdomains, and HTTPS with a visible map.
5. Find the meaningful line in a failed build log.
6. A source rollback versus a database recovery.
7. SEO basics for a public product page.
8. Monitor a critical product flow after publishing.
9. Explain a real monthly cost breakdown.
10. Update a dependency and verify the important behaviour.

Your work and community

1. Why you built Tinct and what you would change.
2. One useful Pickle Royale interaction, start to finish.
3. A GetPosals decision with its alternatives.
4. Revisit a Frabruary exercise with your current judgment.
5. A quiet interaction in Drift.
6. An old AnimeRoar screen and a revised direction.
7. A fictional bilingual invitation with three motion options.
8. A viewer-submitted problem with permission and a scoped fix.
9. A real design disagreement resolved through visible alternatives.
10. A season retrospective: working outputs, failures, and next questions.

Short-form content creates an entry point; setup lessons need enough detail to reproduce. Use three connected pieces when necessary:

The 60-post count is the primary social calendar. Written recipes and optional walkthroughs support those posts, rather than adding separate daily obligations.

Prioritise full recordings for workspace setup, GitHub, connections, database, sign-in/access, file storage, API secrets, deployment, domains, and debugging. For other lessons, a clear written recipe may initially suffice. A later full course can expand every lesson.

Every recipe should contain:

• Who it is for and what will work at the end.
• Previous lesson prerequisites and required accounts/features.
• App/version/plan used and recording date.
• A simple concept diagram or annotated screenshot.
• Exact tested steps and the task prompt where useful.
• Files created or changed, and why.
• Expected result and a visible check.
• Common failure, diagnosis, and recovery.
• Cost incurred in the demonstration, including zero where verified.
• What the demonstration does not yet establish.
• Official reference and a next step.

Provide free plain-text templates with the lesson if you choose. No purchase, course pitch, affiliate funnel, or compulsory email signup is needed for this season.

Explain the purpose first. Start with a brief, instructions, and README; add other files when their information becomes useful. A folder containing many documents is not evidence of better work.

Plain Markdown filenames such as PRD.md and plan.md are conventions you choose; they are not universal automatic memory. Instruct the agent to use them and verify it did. Codex's instruction discovery and Claude's current instruction-file behaviour differ. Claude's current docs also describe AGENTS.md support with version/configuration conditions, so avoid teaching an outdated absolute split between the two products.

Starter brief template

# Product brief
User:
Main task:
Current workaround:
Evidence we have:
Assumptions and questions:
First version:
Excluded for now:
Desired feeling and why:
Success check:

Starter task prompt

Read the current brief and relevant project instructions.
Goal: [observable user outcome].
Current behaviour: [what actually happens].
Relevant evidence: [file/screenshot/reference].
Constraints: [scope, content, platform, access, cost].
Make the smallest coherent change that achieves the goal.
Verify it by [specific action and expected result].
Report what worked, what failed, and any unverified assumption.

Starter milestone template

## Milestone: save and retrieve one reference
Prerequisites:
Scope:
Steps:
Expected result:
Checks:
- Valid input saves.
- Invalid input gets useful feedback.
- Saved record can be retrieved after reopening.
- Access matches the intended owner rules.
Observed result:
Remaining questions:

Starter decision note

## Decision: [plain description]
Date:
Problem:
Options considered:
Choice and reason:
Evidence:
Tradeoff:
What would make us reconsider:

Do not open the season with a lecture containing every term. Introduce one definition at the moment the viewer needs it, then link to this glossary.

Your face stays off-camera. Use real screen recordings, your voice, readable captions, cursor/annotation guidance, diagrams, and selectively hands-only creative footage if you want it.

• Instagram: main daily entry point, WIP, demonstrations, and independently useful companion posts.
• YouTube: sequential playlist and longer follow-along recordings where a task needs them.
• LinkedIn: reuse selected lessons/project stories for professional visibility, with a caption about the problem and decision.
• X: optional observations or one useful screenshot; no separate high-volume schedule.
• A simple public index: episode order, prerequisites, free recipes/templates, official references, and corrections. Creating/publishing that index is a later task.

For complex concepts, carousels may explain a connection better than fast video. For a working interaction, a screen recording is often more direct. Pick the format based on what must be understood.

A core episode's short-form structure

1. Show the action or problem in the first few seconds.
2. Explain the concept in one plain sentence.
3. Trace the important connection or change on screen.
4. Show the result and how you verified it.
5. Point to the follow-along steps and the next prerequisite.

A product/tool exploration

• What can someone do with it?
• Show one complete action.
• Explain the connections or workflow behind that action.
• Give the actual constraints, costs, and access used in your test.
• Mention where it fits in the build series.

A design/research story

• Who was trying to do what?
• What evidence revealed the problem?
• Which alternatives did you consider?
• What did you change and why?
• What evidence supports the result, and what still needs testing?

These structures give tutorials, tool posts, and design stories a common identity without identical scripts.

This expanded season is more demanding than the original short-post plan. Treat it as a small educational production, with reusable recording sessions and a verified teaching project.

Before announcing:

• Prepare the episode outline and choose the exact primary technical route.
• Test the core capstone privately through persistence, access, deployment, and recovery before promising the learning outcome.
• Record a pilot from E01, one own-product exploration, and one design story.
• Time their production and revise the budget.
• Prepare at least eight primary posts, including four consecutive lessons and their companions.
• Prepare full follow-along material for the first complex setup lesson.

During the season:

• Batch related demonstrations from the same project checkpoint.
• Maintain a minimum four-post reserve.
• Keep raw recordings, scripts, assets, and the exact project revision used for a lesson.
• Record a date and tool version on setup-sensitive material.
• Make one clean master for reuse; captions/crops may change per platform.
• Review on a phone: reading size, context, sound, pace, and accidental credential/private-data exposure.
• Add corrections to the episode recipe when tools change.
• Respond to questions by improving the guide or creating a bounded companion post.

Planning estimate for one daily primary post plus supporting recipes and selected longer videos: approximately 12–18 hours/week after the initial teaching-project preparation. A full recorded tutorial for every lesson can require substantially more. These are estimates to replace with pilot measurements, not a promised time budget. Examples built from scratch add to production time.

If that competes with paid work or applications, keep the four-post sequence but publish five times a week. The same season becomes 12 weeks. Scope remains intact; calendar speed changes.

Queue fields

Content ID, calendar slot, type, audience task, prerequisite lesson, source project/revision, hook, concept, demonstration, viewer output, validation, common failure, follow-along link, official source, tool version/date, experiment cost, script status, footage status, edit status, publication status/link, production minutes, and questions received.

Do not require every field for an informal WIP Story. They are useful for reproducible tutorials and the season's primary posts.

Review after cycles 2, 5, 10, and 15. If a prerequisite is confusing, improve its recipe or add a clarification before progressing through an unclear dependency. Do not infer learning from views alone.

Potential viewer checkpoints: a clear brief by E07; a saved repository by E09; a working interface by E15; persistent, access-controlled data by E18; a bounded service integration by E21; a checked deployed version by E23; a reviewed release by E30.

Use actual demonstrations, label mock data, and distinguish an example from a proven client result. Explain account access and costs in the episode that needs them. Do not normalise pasting secrets into public code, turning off permissions to fix errors, fabricating research, or claiming a generated interface is ready for all production uses.

Payments, native app stores, complex collaboration, large-scale search, RAG/embeddings, durable background jobs, realtime multiplayer, advanced shaders, and custom plugins can form later seasons. They belong in the complete subject map, but are optional extensions after the first product is understood. No selling is planned now; a future payment lesson can teach integration using test mode if Dhrumil later chooses it.

Sources consulted via official pages and targeted search, as of 8 October 2026. The links below support tool/concept guidance; the curriculum, sequence, and workload estimates are editorial recommendations.