# Dhrumil's designer-to-product content playbook

Created and researched: 8 October 2026.
Status: editorial strategy and proposed curriculum. No lessons recorded, accounts purchased, products built, posts published, or external messages sent by this task.
This is the expanded direction following Dhrumil's clarification. It supersedes the launch sequence in the earlier faceless design content plan, which remains preserved.

## The intended audience and outcome

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.

## What the online research changes

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

| Finding | Evidence | Implication for your content |
|---|---|---|
| GitHub fundamentals can be introduced without a coding background | [GitHub's Hello World tutorial](https://docs.github.com/en/get-started/using-github/hello-world) begins with repositories, branches, commits, and pull requests | Teach version saving early, through a visible experiment |
| Project instructions, skills, and plugins serve different purposes | [OpenAI skill concepts](https://developers.openai.com/plugins/concepts/skills), [Claude plugin overview](https://code.claude.com/docs/en/plugins) | Explain the distinctions, then demonstrate one useful connection |
| The gap between canvas and running software is narrowing | [Figma's code-to-design workflow](https://www.figma.com/blog/introducing-claude-code-to-figma/) | Include the return journey from a running prototype to editable design |
| Data persistence and access are separate concerns | [Supabase Auth](https://supabase.com/docs/guides/auth), [data access guidance](https://supabase.com/docs/guides/database/secure-data) | Teach saving data and checking who can access it as distinct steps |
| Deployment involves specific connections and configuration | [Cloudflare Git integration](https://developers.cloudflare.com/workers/ci-cd/builds/git-integration/), [Vercel environments](https://vercel.com/docs/deployments/environments) | Show local, preview, and public versions, including configuration differences |
| Media generation may finish later rather than in the initial request | [fal queue documentation](https://fal.ai/docs/documentation/model-apis/inference/queue) | Make waiting, progress, retry, and recovery part of the design lesson |
| 3D work brings a performance budget | [Spline performance guidance](https://docs.spline.design/exporting-your-scene/how-to-optimize-your-scene) | Teach mobile checking, lightweight scenes, and fallback content |
| Research judgment remains necessary | [NN/G's AI study guide](https://www.nngroup.com/articles/ai-work-study-guide/) and [synthetic-user evaluation](https://www.nngroup.com/articles/synthetic-users/) | Use AI to assist with real evidence and distinguish assumptions from findings |

Community discovery also surfaced questions about deployment and managing a codebase without technical knowledge: [nontechnical codebase discussion](https://www.reddit.com/r/vibecoding/comments/1kjr9eq/how_do_nontechnical_creators_in_the_vibe_coding/). 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.

## The content structure

### 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.

| Reference | What its visible content does | What you can learn for your own series |
|---|---|---|
| [Ship Your First Thing](https://shipyourfirstthing.com/) | Organises nontechnical learning around a first build, mental models, recovery, and operating the product | Give viewers a concrete output and explain concepts when the build needs them |
| [Claude Code for Designers](https://claudefordesigners.com/) | Presents a project-led designer curriculum including APIs, storage, deployment, and visual iteration | Use recognisable design tasks as entry points into technical topics |
| [Asutosh's first interactive Codex design guide](https://asyoutosh.com/guides/how-to-use-codex/) | Shows an empty-folder-to-interface sequence with planning, preview, iteration, context files, and light Git | Capture the workspace and exact sequence so viewers can locate themselves |
| [Figma's AI app-building guide](https://www.figma.com/resource-library/how-to-build-an-app-with-ai/) | Provides a broad staged overview of AI-assisted app creation | Keep a clear product journey while supplying more detailed follow-along material for each connection |

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:

| Position | Content type | Purpose |
|---|---|---|
| 1 | Build series, episode 1 | Teach the next prerequisite |
| 2 | Product, tool, or API exploration | Show a useful application or your own work |
| 3 | Build series, episode 2 | Continue the learning path |
| 4 | Design decision or research story | Show how judgment improves the product |

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.

## A single teaching product

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:

```text
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.

## Recommended tools and plan choices

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.

| Need | Starting recommendation | When to add or upgrade | Source |
|---|---|---|---|
| Coding agent | Use existing suitable Claude Code or Codex access; select one for following along | Upgrade after observing repeated usage constraints on real tasks | [Claude access](https://support.claude.com/en/articles/11145838-use-claude-code-with-your-pro-or-max-plan), [Codex pricing/access](https://learn.chatgpt.com/docs/pricing) |
| Versions and remote repository | GitHub Free; GitHub Desktop for a visible interface if helpful | Paid features when a real collaboration or control requirement appears | [GitHub plans](https://github.com/pricing), [Desktop workflow](https://docs.github.com/en/desktop/overview/about-github-desktop) |
| Design canvas | Existing Figma access or screenshots/wireframes | A connector when it solves an actual transfer/context task | [Figma workflow](https://www.figma.com/blog/introducing-claude-code-to-figma/) |
| Hosting for this teaching route | Cloudflare Workers with static assets and backend routes where needed | Paid capacity when required by usage or selected features | [Static assets](https://developers.cloudflare.com/workers/static-assets/), [pricing](https://developers.cloudflare.com/workers/platform/pricing/) |
| Database, sign-in, file storage | Supabase for the primary beginner demonstration | Upgrade when its actual limits, reliability requirements, or features warrant it | [Auth](https://supabase.com/docs/guides/auth), [pricing](https://supabase.com/pricing) |
| Alternative data route | Cloudflare D1, with access checks implemented in your backend; R2 for files | Useful for explaining another architecture after the primary route | [D1](https://developers.cloudflare.com/d1/), [R2](https://developers.cloudflare.com/r2/) |
| Alternative hosting | Vercel for a framework/project that suits it | Choose the appropriate plan for the intended usage | [Git deployments](https://vercel.com/docs/git), [Hobby terms](https://vercel.com/docs/plans/hobby) |
| Images | Existing image-generation access for art direction; an API only when integrating generation into the product | Add controlled API usage for a tested feature | [OpenAI image API](https://developers.openai.com/api/docs/guides/image-generation) |
| Video | A selected provider used in a bounded experiment | Add generation credits when making the actual media example | [Runway API](https://docs.dev.runwayml.com/guides/using-the-api/), [fal queue](https://fal.ai/docs/documentation/model-apis/inference/queue) |
| Web animation | Start with a simple transition; explore GSAP for sequencing | Use richer tooling when interaction requires it | [GSAP](https://gsap.com/docs/v3/GSAP/) |
| Programmatic video | Remotion as a separate creative exploration | Investigate setup, rendering cost, and licence for the intended use | [Remotion](https://www.remotion.dev/docs/) |
| 3D | A small Spline embed first; Three.js as an advanced alternative | Add code-level control for a specific requirement | [Spline export](https://docs.spline.design/exporting-your-scene/web/exporting-as-public-ur-ls), [Three.js scene](https://threejs.org/manual/pages/creating-a-scene.html) |

### 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](https://learn.chatgpt.com/docs/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](https://claude.com/pricing). Its [Claude Code access guide](https://support.claude.com/en/articles/11145838-use-claude-code-with-your-pro-or-max-plan) explains subscription access and API-key billing behaviour.
- GitHub Free is $0 and supports public/private repositories: [GitHub pricing](https://github.com/pricing).
- Cloudflare Workers has a Free plan and a Paid plan with a $5/month minimum plus applicable usage: [Workers pricing](https://developers.cloudflare.com/workers/platform/pricing/).
- Supabase has a Free plan; Pro is listed at $25/month with compute/usage considerations: [Supabase pricing](https://supabase.com/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.

## The 30 core episode briefs

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.

## The 60-post calendar

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.

| Cycle / days | First post: series | Second post: exploration | Third post: series | Fourth post: design/research story |
|---|---|---|---|---|
| 1 / 1–4 | E01: how a product connects | P01: Tinct, what it does and why I built it | E02: accounts, plans, and costs | D01: a colour decision, tested in a real component |
| 2 / 5–8 | E03: local files and preview | P02: Drift, a working focus-tool walkthrough | E04: problem, research, and scope | D02: making a product ask less of its user |
| 3 / 9–12 | E05: useful inspiration | P03: one Frabruary exercise revisited | E06: project .md files | D03: references translated into a distinct direction |
| 4 / 13–16 | E07: milestones and completion | P04: Pickle Royale, one useful flow | E08: Git/GitHub save and push | D04: simplifying a setup flow and explaining the tradeoff |
| 5 / 17–20 | E09: branch, review, recovery | P05: a public Framer site and its working behaviour | E10: focused prompts and context | D05: a mobile layout decision that changed the structure |
| 6 / 21–24 | E11: plugins/MCP/connectors | P06: one actual Figma connection demonstrated | E12: a reusable design skill | D06: inconsistent components brought into one system |
| 7 / 25–28 | E13: Figma/flow to build context | P07: GetPosals, one workflow you owned | E14: first working interaction | D07: making the main action discoverable |
| 8 / 29–32 | E15: responsive states | P08: cloud data versus browser-only saving | E16: data model and storage choices | D08: an empty state that guides the next action |
| 9 / 33–36 | E17: database persistence | P09: D1 and Supabase, same need/different architecture | E18: sign-in and ownership | D09: dense information organised for a decision, with synthetic data |
| 10 / 37–40 | E19: file storage | P10: a small image-generation API feature demo | E20: API and secret boundary | D10: making a failed upload recoverable |
| 11 / 41–44 | E21: useful AI feature | P11: fal/Runway request, waiting, result, and actual experiment cost | E22: GitHub to Cloudflare deployment | D11: honest progress and recovery during a long request |
| 12 / 45–48 | E23: domains and environments | P12: your deployed personal product, traced through its actual services | E24: image direction and integration | D12: choosing imagery that helps the page communicate |
| 13 / 49–52 | E25: video and interactive motion | P13: invitation workflow, fictionalised or cleared for sharing | E26: a small 3D experience | D13: timing and motion that preserve orientation |
| 14 / 53–56 | E27: complete-flow testing | P14: a repeatable browser check demonstrated | E28: debugging and recovery | D14: one bug that revealed a design-state gap |
| 15 / 57–60 | E29: real feedback and revisions | P15: a before/after of your own earlier work | E30: release and maintenance | D15: what this season taught you about designing and shipping |

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.

## How to frame your own products

| Source | What to teach through it | Evidence to capture | What to keep explicit |
|---|---|---|---|
| Tinct | Colour roles, constraints, applying a system | Input, output, actual component use | A palette alone is not proof of accessible design |
| Pickle Royale | Flow design, data, state, product decisions | One complete real workflow | Demo state versus persisted/shared data |
| GetPosals | Complex actions, proposal workflow, ownership | Public/cleared screen and your decision | Your contribution versus team contributions |
| Drift | Restraint, sound/control, low-demand interactions | Working control and its feedback | Design intent versus proven user outcome |
| Frabruary exercises | Range, deliberate iteration, craft | Earlier/final exercise and one revision | Exercise versus client/production product |
| Framer sites | Responsive layouts, CMS where relevant, delivery | Actual site behaviour and your changes | What you designed/built and any collaborator credit |
| AnimeRoar | How your thinking evolved | An old screen and a thoughtful revision | Concept work and asset attribution |
| Inspiration-memory example | Inspiration memory and retrieval | A fictionalised public example of the principle | Demonstrate with a fictional dataset |
| Invitations | Motion, typography, media production | Cleared or fictional details, original sequence | Do not publish another person's event details without clearance |
| Healthcare/enterprise work | Dense information, roles, decision-making | Cleared material or synthetic recreations | No patient data, confidential screens, invented metrics |

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

## 120 additional topic ideas

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

11. Annotate a reference instead of merely collecting it.
12. Separate visual inspiration from interaction inspiration.
13. Explain which parts of a reference do not fit your context.
14. Combine compatible principles from different references.
15. Make an original variation of your own older screen.
16. Design one task for calm versus urgency.
17. Choose typography by content and reading task.
18. Test a colour system in success/error states.
19. Use your own photograph to build an asset direction.
20. Keep useful source attribution in a reference library.

### Project files and context

21. Markdown in five visible formatting examples.
22. README versus product brief versus PRD.
23. What belongs in agent instructions.
24. How to confirm an agent read the intended file.
25. Stale documents that contradict the build.
26. Decision logs that explain why something changed.
27. Session summaries that help you resume work.
28. A changelog written for someone who uses the product.
29. Keeping project guidance short enough to be useful.
30. Tool-specific file-loading differences in your installed versions.

### AI tools and extensions

31. Browser chat versus an agent working on local files.
32. A plugin, connector, MCP server, and API compared through one task.
33. Read access versus write access in a connected app.
34. Choosing a plugin because you need a capability.
35. A skill used successfully on two projects.
36. A skill that loads irrelevant instructions and how you fix it.
37. Reproducing one tool comparison with matched inputs.
38. Model/effort selection measured on one specific task.
39. Scheduled tasks, useful triggers, and what they should report.
40. Parallel agent work: when it helps, integration cost, and why one agent may suffice.

### Files, Git, and collaboration

41. Local files versus files stored in a remote repository.
42. GitHub Desktop through a visible layout change.
43. What a useful commit message says.
44. A branch for a design alternative.
45. Inspect a diff without reading every line of code.
46. A pull request description tied to visible behaviour.
47. Public code, private code, and public deployments.
48. What .gitignore does and does not undo.
49. A merge conflict explained with two versions of a text file.
50. Recover a known working code version while preserving current work.

### Building interfaces

51. HTML, CSS, and JavaScript through one real control.
52. Why a project uses a framework.
53. Packages, package managers, and lockfiles.
54. What localhost and a port mean.
55. A component with explicit behaviour and states.
56. Realistic content as a layout stress test.
57. Responsive reorganisation versus shrinking.
58. An accessible keyboard path through a form.
59. Design tokens used in the actual build.
60. Bring an implemented interface back into editable design context.

### Databases and storage

61. A table shown beside the screen that reads it.
62. IDs and relationships in a reference library.
63. Refresh persistence versus cross-device persistence.
64. Browser storage versus database-backed storage.
65. Database records versus image/video files.
66. A schema change and why it needs a migration.
67. Sample data and real data kept separate.
68. D1 versus hosted Postgres for a specific project.
69. Export your notes and preserve media references.
70. Backups and an actual recovery demonstration.

### Accounts and permissions

71. Authentication versus authorisation in one example.
72. Two test accounts checking data isolation.
73. Why a hidden button does not protect an action.
74. An owner field and a matching access policy.
75. Sign-in callbacks across local and deployed URLs.
76. Expired sessions and helpful recovery.
77. Publishable keys versus private service credentials.
78. Role-based actions in a small admin interface.
79. Private files and controlled download links.
80. Account/data export and deletion design, with proper confirmation.

### APIs and automation

81. A request and response shown as a product action.
82. JSON explained using a reference record.
83. A backend route keeping a provider secret private.
84. Environment configuration across local and preview.
85. CORS explained through a controlled example.
86. Request limits and a useful retry message.
87. Polling versus a webhook for a long task.
88. Prevent duplicate submissions and duplicate spending.
89. Connect email or a calendar using current provider guidance.
90. Build an AI feature that still leaves the user in control.

### Creative media and 3D

91. Reference-driven image art direction.
92. Edit a specific image detail without changing the composition.
93. Crop the same asset for desktop and mobile.
94. Image-to-video with controlled camera/motion intent.
95. Storyboard a short product film before generation.
96. A reusable typography video made with code.
97. CSS motion versus a GSAP timeline.
98. Spline embed versus a Three.js implementation.
99. Optimise one 3D scene for a phone.
100. A static/reduced-motion fallback that preserves the message.

### Publishing and maintenance

101. GitHub to Cloudflare connection, traced end to end.
102. Choose hosting based on the build's runtime needs.
103. Preview URL versus custom domain.
104. DNS, subdomains, and HTTPS with a visible map.
105. Find the meaningful line in a failed build log.
106. A source rollback versus a database recovery.
107. SEO basics for a public product page.
108. Monitor a critical product flow after publishing.
109. Explain a real monthly cost breakdown.
110. Update a dependency and verify the important behaviour.

### Your work and community

111. Why you built Tinct and what you would change.
112. One useful Pickle Royale interaction, start to finish.
113. A GetPosals decision with its alternatives.
114. Revisit a Frabruary exercise with your current judgment.
115. A quiet interaction in Drift.
116. An old AnimeRoar screen and a revised direction.
117. A fictional bilingual invitation with three motion options.
118. A viewer-submitted problem with permission and a scoped fix.
119. A real design disagreement resolved through visible alternatives.
120. A season retrospective: working outputs, failures, and next questions.

## The learning materials each episode needs

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

| Material | Role | Recommended treatment |
|---|---|---|
| Primary social post | Make the concept and result understandable | 60–120 seconds, or a readable carousel |
| Follow-along recipe | Make the task reproducible | Prerequisites, screenshots/steps, prompt, expected result, checks, recovery |
| Longer recording for complex steps | Show setup and debugging without skipping necessary actions | Roughly 8–20 minutes where the task warrants it |

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.

## A small document system to teach

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.

| File | What it answers | How the agent uses it |
|---|---|---|
| README.md | What is this project, and how do I run it? | Explicit reference for setup and project orientation |
| brief.md / PRD.md | Who is it for, what should it do, and what is excluded? | Read before planning/changing product behaviour |
| references.md | What inspired which decision, and where did it come from? | Read for the relevant design task |
| design.md | What visual/interaction principles fit this product? | Read before design/build/review tasks |
| plan.md | What milestones depend on what, and how are they checked? | Updated during the scoped task |
| decisions.md | Why did we choose this route over the alternatives? | Reference when reconsidering a choice |
| tests.md | Which behaviours need to be verified? | Use for manual acceptance; automated tests live separately |
| status.md / changelog.md | What works, what changed, and what remains? | Read when resuming work; keep current |
| AGENTS.md | What instructions should a supported agent use? | Tool-specific discovery; confirm actual loading |
| CLAUDE.md | What persistent guidance should Claude Code receive? | Tool-specific loading and references |
| SKILL.md inside a skill folder | How should a repeatable scoped workflow be performed? | Load when the workflow applies |

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](https://learn.chatgpt.com/docs/agent-configuration/agents-md) and [Claude's current instruction-file behaviour](https://code.claude.com/docs/en/memory) 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

```markdown
# 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

```text
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

```markdown
## 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

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

## A plain-language glossary to reveal when needed

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.

| Term | Plain explanation |
|---|---|
| Frontend | The interface and behaviour running in the user's browser/app |
| Backend | Trusted service logic used to handle requests, protected actions, or integrations |
| Full stack | Work involving both interface and backend/data systems |
| Runtime | The software environment that executes a program |
| Framework | A reusable structure and conventions for building software |
| Package/dependency | Existing code your project installs and uses |
| Package manager | A tool that installs and tracks those dependencies |
| Lockfile | A record used to reproduce selected dependency versions |
| Terminal | A text interface for asking the computer to perform commands |
| Localhost | An address for a service running on your own computer |
| Port | A numbered endpoint used to reach a particular local/network service |
| Build | Preparing the project into a form the target environment can run/serve |
| Repository | A project stored with tracked version history |
| Git | A system for tracking versions of files |
| GitHub | A service for hosting Git repositories and collaboration workflows |
| Commit | A named checkpoint of tracked changes |
| Branch | A separate line of work that can later be compared or combined |
| Push/pull | Sending/fetching repository changes to/from a remote |
| Pull request | A proposed change with a comparison and review discussion |
| Diff | A view of what changed between versions |
| Merge | Combining changes into another line of work |
| Deployment | Putting a build onto the environment that serves/runs it |
| Preview | A deployed version used to review a change before release |
| Production | The environment used by the intended real users |
| Domain | A human-readable name used to reach a service |
| DNS | The system that resolves names using configured records |
| HTTPS | An encrypted web connection with authenticated server identity |
| Database | A system that stores and queries structured records |
| Schema | The structure and constraints of the stored data |
| Migration | A tracked change to database structure |
| Object/file storage | A place for uploaded or generated files, with its own access rules |
| Authentication | Checking who a user is |
| Authorisation | Checking what that user may do or access |
| Session | State representing an ongoing signed-in interaction |
| RLS | Database rules controlling access to individual rows |
| API | A defined way for software to request another system's capability/data |
| Endpoint | A particular API address for an operation |
| JSON | A common text format for structured data |
| SDK | A provider's code tools that simplify using its API |
| Environment variable | Configuration passed into a running/building environment |
| Secret | A credential that must not be exposed to unauthorised users |
| Webhook | A service notifying another endpoint about an event |
| Polling | Asking repeatedly whether a task has changed/completed |
| Rate limit | A restriction on how often/how much a service can be called |
| CORS | Browser rules controlling certain cross-origin requests; not a replacement for access checks |
| Token | A unit used in model text processing; also a term used for credentials in other contexts |
| Context window | The amount of information a model can consider in a particular interaction |
| MCP | A protocol for connecting AI clients to external tools/resources |
| Connector | An integration granting access to a service/account |
| Skill | Scoped instructions/resources for a repeatable workflow |
| Plugin | A packaged extension; exact components differ by product |
| Hook | A configured action triggered at a defined lifecycle event |
| Agent | A model-driven system that can work through tasks using tools |
| Markdown | Plain text with simple formatting conventions, commonly saved as .md |
| Shader | A graphics program controlling how pixels or surfaces are rendered |
| Scene | The collection of objects/lights and other elements in a 3D experience |
| Regression check | A check that previously intended behaviour still works after a change |
| Rollback | Returning running software to an earlier version; data recovery may be separate |

## Formats and platforms

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.

## Production and launch

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.

## Measuring useful progress

| Goal | Evidence to watch |
|---|---|
| Learners understand the connections | Questions become more specific; viewers can explain where their data or API call lives |
| Learners can follow the process | They complete the intended output and identify the same verification step |
| Content is relevant | Saves/shares, substantive replies, returning viewers, and guide visits |
| Your work is visible | Relevant portfolio visits and conversations about your decisions/builds |
| The production is sustainable | Actual minutes per piece, reserve size, and interference with paid work/applications |

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.

## Editorial boundaries and later seasons

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.

## Official source directory

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.

| Source | Useful for |
|---|---|
| [Codex pricing/access](https://learn.chatgpt.com/docs/pricing) | App plans, limits, and API-key billing distinction |
| [Codex AGENTS.md](https://learn.chatgpt.com/docs/agent-configuration/agents-md) | Project instruction discovery |
| [OpenAI skills](https://developers.openai.com/plugins/concepts/skills) | Scoped reusable workflow instructions |
| [OpenAI plugin packaging](https://developers.openai.com/plugins/build/plugins) | Extension packages and connected capabilities |
| [OpenAI image generation](https://developers.openai.com/api/docs/guides/image-generation) | Image creation/editing via API |
| [Claude pricing](https://claude.com/pricing) | Current subscription choices |
| [Claude Code subscription access](https://support.claude.com/en/articles/11145838-use-claude-code-with-your-pro-or-max-plan) | Access, limits, and authentication/billing behaviour |
| [Claude Code memory](https://code.claude.com/docs/en/memory) | Persistent guidance and instruction-file conditions |
| [Claude Code skills](https://code.claude.com/docs/en/skills) | Reusable scoped workflows |
| [Claude Code plugins](https://code.claude.com/docs/en/plugins) | Packaging extension components |
| [Claude Design guide](https://support.claude.com/en/articles/14604416-get-started-with-claude-design) | Reference inputs and iterative design |
| [GitHub Hello World](https://docs.github.com/en/get-started/using-github/hello-world) | Repositories, branches, commits, review |
| [GitHub Desktop](https://docs.github.com/en/desktop/overview/about-github-desktop) | A visible Git workflow |
| [GitHub pricing](https://github.com/pricing) | Free repository access and plan choices |
| [Cloudflare static assets](https://developers.cloudflare.com/workers/static-assets/) | Serving a frontend alongside Worker logic |
| [Cloudflare Git integration](https://developers.cloudflare.com/workers/ci-cd/builds/git-integration/) | Connecting repository changes to deployment |
| [Cloudflare Workers pricing](https://developers.cloudflare.com/workers/platform/pricing/) | Free/Paid and usage costs |
| [Cloudflare D1](https://developers.cloudflare.com/d1/) | Managed SQLite-compatible data route |
| [Cloudflare R2](https://developers.cloudflare.com/r2/) | File/object storage |
| [Supabase Auth](https://supabase.com/docs/guides/auth) | Identity and access concepts |
| [Supabase securing data](https://supabase.com/docs/guides/database/secure-data) | Access policies and credential boundaries |
| [Supabase pricing](https://supabase.com/pricing) | Plan, compute, and included usage |
| [Supabase billing explanation](https://supabase.com/docs/guides/platform/billing-on-supabase) | Separate compute/add-on/usage considerations |
| [Vercel Git deployments](https://vercel.com/docs/git) | Alternative repository/deployment route |
| [Vercel environments](https://vercel.com/docs/deployments/environments) | Local, preview, and production context |
| [Vercel Hobby](https://vercel.com/docs/plans/hobby) | Appropriate use of that plan |
| [Figma code-to-design](https://www.figma.com/blog/introducing-claude-code-to-figma/) | Working-interface/canvas round trip |
| [MDN files/workspace](https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Environment_setup/Dealing_with_files) | Basic project organisation |
| [fal queue](https://fal.ai/docs/documentation/model-apis/inference/queue) | Long-running model tasks and result retrieval |
| [Runway API](https://docs.dev.runwayml.com/guides/using-the-api/) | A video-generation integration example |
| [GSAP](https://gsap.com/docs/v3/GSAP/) | Interactive animation sequencing |
| [Remotion](https://www.remotion.dev/docs/) | Programmatic video creation |
| [Spline export](https://docs.spline.design/exporting-your-scene/web/exporting-as-public-ur-ls) | Sharing/embedding a 3D scene |
| [Spline optimisation](https://docs.spline.design/exporting-your-scene/how-to-optimize-your-scene) | Scene performance considerations |
| [Three.js scene](https://threejs.org/manual/pages/creating-a-scene.html) | Scene/camera/renderer basics |
| [Playwright tests](https://playwright.dev/docs/writing-tests) | Repeatable behaviour checks |
| [NN/G AI study guide](https://www.nngroup.com/articles/ai-work-study-guide/) | AI use within UX work |
| [NN/G synthetic users](https://www.nngroup.com/articles/synthetic-users/) | Evidence limitations |
| [NN/G task scenarios](https://www.nngroup.com/articles/task-scenarios-usability-testing/) | Realistic usability tasks |