Module 2, Lesson 3: Generating the Technical Document

Before We Start

Here's what I'd expect you to have in place before this lesson:

From previous lessons:

• Your completed market research document from Module 2, Lessons 1 and 2 — saved in Obsidian or your notes tool of choice. Claude writes the technical document based on this, so it needs to exist and be accessible.
• Your project folder set up in Claude Desktop's Cowork tab — you'll configure this at the start of the lesson if you haven't already

Tools / setup you'll need:

• Claude Desktop (the local desktop app — not the browser version)
• Obsidian with your research document already saved inside it
• The Claude Cowork tab available in your Desktop app

By the end of this lesson, you'll:

• Have an app name you've validated (not just vibed with)
• Understand what the technical document is and why it exists before you write a single line of code
• Have used Claude's Cowork mode to generate a full technical architecture document and write it directly to your folder
• Know how to read and work with the document Claude produces

About This Lesson

Duration: ~20 minutes video + ~30 minutes for your own run
Skill Level: Intermediate
What You'll Build: A technical overview document — your app's architecture, stack choices, cost projections, and environment setup — saved directly into your project folder

This is the first document in the documentation phase. It's the one that answers the question: "What, exactly, are we building and how?" Even if you hand this off to an agency instead of building it yourself, this document gives whoever's building it a clear blueprint to work from.

Watch the Lesson

What We're Covering

Here's what I'm walking you through in this lesson and why it matters:

• Naming your app with Claude — how to use AI as a naming partner without just going with whatever it says first
• Validating the name — domain availability, trademark check, and what to look for before you commit
• The four documents this module produces — what each one is for and how they connect
• Setting up Claude's Cowork tab — what it is, how it connects to your folder, and why this is different from a regular chat
• The technical document prompt — the structure behind the prompt and why each section exists
• Reading the output — what Claude produces and how to work with it

1. Let's Set the Scene (~0:00)

Before I start generating any documents, I want to give the app a proper name. We've been calling it "the co-parenting app" — which works for talking about it, but doesn't work for building it. Your file names, your folder structure, your prompts — they all need a consistent identifier.

So in this lesson, I'm naming the app first. Then I'm generating the technical document. And I want to show you how I used Claude to help with the naming — and, importantly, how I pushed back on what it first suggested.

In this module overall, we're going to produce four documents. The technical document is first. Then we'll generate a UX and branding overview. Then a stakeholder summary — which is helpful even if the only stakeholder is you, because it forces you to articulate what you're building as if you're pitching it. And finally, a go-to-market document. Combined with the research report from the previous two lessons, that's five foundational documents before we write a single line of code.

That might sound like a lot. But every one of those documents feeds something downstream — and the time you spend here makes everything that comes after significantly faster.

2. Naming the App

2.1 How I Prompted for Names

My app doesn't have a name yet, so before I generate any documents, I want one. And yes — I'm going to use Claude to help.

Here's the prompt structure I used:

Based on the research and the sensitivity of what the name can imply, 
can you suggest names for my app? For context, here's a quote from an 
App Store review I found: [paste the review quote you found earlier].

If you need any clarity before suggesting names, ask me first.

That last line — asking Claude to ask me questions before diving in — is something I use consistently. It gets much better results than just letting it guess what you want.

Claude came back with a set of clarifying questions before giving me any names:

1. What emotional tone do you want the app to convey? (Calm? Empowering? Professional? Playful?)
2. How explicitly should the name signal the app's purpose? (Should people instantly know it's for co-parents, or something more subtle?)
3. Any words or associations to avoid?

These questions aren't Claude padding things out. They're genuinely useful to answer — because they force you to be clear about things you might have left fuzzy.

2.2 My Answers and Why

Here's how I answered:

Tone: Calm and conflict-reducing, empowering, child-focused, and neutral-practical. I kept the "modern and professional" option off — that leaned too corporate for what I wanted.

Explicitness: Somewhere in the middle. I want people to roughly understand what it does, but not so literal that it becomes uncomfortable for someone who has to have it on their phone. Co-parenting situations can be fraught — a name that screams "DIVORCE APP" could feel triggering. But too vague and it's forgettable.

Words to avoid: Anything implying conflict, courts, or legal proceedings. Avoid "co" as a prefix (feels too clinical and potentially uncomfortable). Avoid generic-sounding names and coined names that feel fake.

2.3 Evaluating What Claude Suggested

Claude came back with a batch of names: Keto, Wellwise, Nora, Clarity, Parento, Kindpath, Parallel, Tandem, Anoma.

None of them were quite right. I pushed it for more — specifically asking for "more branded" options. Claude ran another round (this is where it mentioned it was running sub-agents, doing combinations and variations) and came back with a second batch.

Out of everything it suggested, two stood out to me:

• Twine — something about it felt connective. You say it and it sounds like something real.
• Nurturo — modern, soft, no hard sounds. Close to "nurture" without being on the nose.

The rest I discarded. And this is an important point: AI is a great brainstorming partner, but your human judgment on naming still matters. You're the one who knows what feels right for the market you've spent time researching. Claude gives you direction. You decide where to actually steer.

2.4 Validating the Name Before You Commit

Once I had Nurturo as my top choice, I did three quick checks before going any further:

1. Google search: Is anyone already using this name in a meaningful way? I didn't find much — which is a good sign.

2. Domain availability: I went to Namecheap and checked nurturo.com and nurturo.app. The .com was taken (and listed for sale at around $7,000 — which I'm not paying, but interestingly that price signals the name has brand power). The .app was available at roughly $12/year. That's the one I'm going for.

3. Trademark check: I did a quick search on the US Patent and Trademark Office website (USPTO). Nobody had a registered trademark on Nurturo. Green light.

That whole validation process took less than 10 minutes. Do it before you get attached to a name and start building with it.

2.5 Updating Your Files

Once I had a name, I went back to Obsidian and renamed my research files. I went from a generic "research" naming to a consistent pattern:

[AppName] Market Research
[AppName] Market Review

In my case, that's Nurturo Market Research and Nurturo Market Review. I also renamed any related files to match. This consistent naming becomes important later — Claude's prompts reference files by name, and you want that to be predictable and clean.

3. The Four Documents This Module Produces

Before we generate the technical document, I want to give you the full picture of what this module produces. We're not just making one thing — we're making four, and they build on each other:

1. Technical Document — what we're building, how it's built, what stack it runs on, what it costs to operate. This is the engineering blueprint.
2. UX / Branding Document — how the app looks and feels, the experience and tone, key design principles.
3. Stakeholder Summary — a concise pitch-style document explaining what the product is, who it's for, and why it matters. Even if the only stakeholder is you, this forces clarity.
4. GTM (Go-to-Market) Document — how you're going to launch, acquire users, and position the product in the market.

Plus, from the previous two lessons, you already have the market research. So by the time you finish this module, you'll have five comprehensive documents — all grounded in real research — before a single line of code is written. That's the foundation everything else builds on.

In this lesson, we're doing the first one: the technical document.

4. Setting Up Claude's Cowork Tab

4.1 What Cowork Is

Cowork is a tab inside Claude Desktop. It's not a regular chat — it's a workspace mode where Claude can see and work with files on your computer directly. When you open Cowork and select a folder, Claude has access to everything in that folder. It can read your documents, write new ones, and update existing ones — without you having to paste anything in.

This is why the desktop app is required. The browser version of Claude.ai doesn't have Cowork, and it doesn't have the file access Claude needs for this to work.

4.2 Selecting Your Folder

When you open Cowork, the first thing you'll see is a prompt to select a folder. Click it and navigate to wherever you're storing your project documents — in my case, the folder inside my Dropbox that contains my Obsidian vault files for this project.

A few things to keep in mind about your folder selection:

• Keep it focused. Select the folder that contains only your project documents, not your entire Dropbox or desktop. Claude will read everything in that folder as context — so a huge folder with unrelated files will slow things down and muddy the context.
• The folder needs to already exist. Create it and move your existing files in before you open Cowork.
• The path shows up in Cowork. Once selected, you can see the path in the corner — double-check that it's pointing to the right place before you run any prompts.

After selecting the folder, you should see your files listed in the Cowork sidebar. If you can see your market research document listed there — you're set up correctly and ready to go.

5. The Technical Document Prompt

5.1 Why I Wrote a Long Prompt (And Why You Should Use It)

This prompt took me a while to get right. I've iterated it over multiple projects, and what you'll find in the prompt library is the version I actually use — not a first draft.

I know long prompts can feel intimidating. But think of it this way: you're giving Claude the information it would need to brief a senior technical architect. The more precisely you do that, the better the output you get back. A vague prompt produces a generic document. A specific prompt produces something you can actually work with.

You don't need to write this prompt yourself — it's in Section 5.2 below. But I want to walk you through its structure so you understand what it's doing and can adapt it for your project.

5.2 The Prompt

Here's the full prompt. Fill in the three placeholders before you run it: replace {{product_name}} with your app name (e.g. Nurturo), {{monthly_budget}} with your infrastructure budget (e.g. $500), and {{team_size}} with your team size (e.g. 2-3 developers). Everything else copies as-is.

You are a senior technical architect specialising in SaaS products for solopreneurs and lean teams.

You will find the market research in the folder for a new product.

Your job is to produce a comprehensive Technical Overview document in Markdown.

Output filename: App - {{product_name}} - Technical.md

---

## Input

You will receive:

1. A market research report (in the folder) — this is your primary source for understanding what the product does, who it serves, its pricing, competitive landscape, and any technical notes the researcher included.
2. Product name — it is in the research file name.
3. Product description — defer to the market research. Do not ask.

---

## Stack Selection

Choose the best technology for this specific product. Do not apply a generic template.

Before selecting any technology, reason through these questions:

- Platform: Is this product mobile-first, web-first, or both? What do the competitors use, and what does the target user expect on their device?
- Scale: What's the expected user volume at MVP vs. 12 months in? Does that change the infrastructure needs?
- Domain: Are there standard tools or compliance requirements for this product's category (e.g. healthcare, finance, communication, productivity)?
- Complexity: Does the product require real-time sync, background processing, AI inference, file storage, or other non-trivial infrastructure? Choose accordingly.
- Maintainability: With a small team, prefer well-documented, widely adopted technologies over niche choices. The person maintaining this is probably one person.

Justify every technology choice in 1-2 sentences. If you choose between two reasonable options, briefly note why you picked one over the other.

---

## Constraints

- Budget: ~{{monthly_budget}} total infrastructure per month at early scale (0-500 users)
- Team: {{team_size}}
- Depth: Architecture-level only — describe what each component does, how they connect, and why they were chosen. Do not write implementation code. Pseudocode or interface signatures are acceptable only when they clarify architecture (e.g. a provider fallback chain, a job processing pipeline).
- Free tiers: Identify and prefer services with meaningful free tiers for the MVP stage. State clearly which services cost nothing at early scale.

---

## Document Structure

Follow this structure precisely. Every section is required unless marked (if applicable).

### 1. Stack Summary

A single table listing every technology in the stack, with columns: Layer, Technology, Notes. Group by concern area (e.g. Frontend, Backend, Database, Auth, Infrastructure, Monitoring, Third-Party).

### 2. Key Architectural Decisions (if applicable)

If the product requires a non-obvious architectural choice (e.g. a multi-provider AI strategy, a reseller API model, a real-time sync engine, a mobile-first vs. API-first split), dedicate a section to explaining:

- What the decision is
- Why it was made (cite the research)
- How it works at a high level
- A comparison table if relevant

### 3. Infrastructure

Cover:

- Hosting & Deployment — Dev and prod environments, CI/CD pipeline
- Database Schema (Core Tables) — Mermaid diagram showing tables, key columns, and relationships. Core domain tables only (typically 5-10 tables).
- Background Jobs — Table of scheduled/triggered jobs: Job name, Schedule/Trigger, Purpose
- Third-Party Integrations — Table of every external service: Service, Purpose, Tier/Cost at MVP scale

### 4. Authentication & Security

Cover:

- Auth approach — what library or service handles it, and how it is configured for this product
- Data handling policies — what is stored, what is transient, retention periods
- Compliance considerations — GDPR, CCPA, or industry-specific requirements relevant to this product's domain
- Security measures — encryption, rate limiting, CORS, input validation
- Third-party data policies — especially for any AI or data-processing APIs

### 5. API Architecture

- Internal API — Tree diagram of API routes grouped by domain
- External APIs Consumed — Table: API, Purpose, Auth Method
- Key Abstractions — If the product wraps external APIs, describe the abstraction layer at interface level (not implementation)

### 6. Cost Projections

- Per-unit cost breakdowns where applicable (e.g. AI cost per token, storage cost per GB, API cost per call)
- Monthly Cost Projections — Table with three stages: MVP (0-100 users), Growth (100-500 users), Scale (500-2K users). Columns: Stage, Monthly Cost, Breakdown
- Unit Economics — Average cost per user, gross margin at each pricing tier
- Free tier summary — Which services cost nothing at MVP stage and when costs kick in

### 7. Environment Variables

List all required and optional environment variables, grouped by service. Use placeholder values. Mark each as Required or Optional. Do not include actual secrets.

### 8. Development Setup

Step-by-step shell commands to clone, install, configure, and run the project locally. State your assumptions about what the developer already has installed (e.g. Node.js, pnpm, Docker).

### 9. Third-Party Service Setup

For each product-specific service (anything that requires a signup or account), provide:

- Service name and signup URL
- Key configuration steps (2-4 bullets)
- Which model, tier, or plan to use at MVP stage

### 10. Deployment Checklist

Three checklists:

- Pre-Launch — Infrastructure, DNS, SSL, database, env vars, API keys, third-party accounts
- Launch Day — Migrations, deploy, integration verification, critical flow testing, monitoring
- Post-Launch — Backups, alerting, cost monitoring, runbooks, security update cadence

---

## Research & Gap-Filling

- Use the market research as your primary source for understanding the product domain, competitors, pricing expectations, and technical requirements.
- Search the web to fill gaps on: current pricing of third-party services, best practices for this product's domain, and any technology choices not covered in the research.
- Use real, current pricing — if the research figures seem outdated, search and use the current price. Do not estimate.
- Cite your reasoning — when you choose a technology over alternatives, state why in 1-2 sentences.

---

## Quality Standards

- Every table must be properly formatted Markdown.
- Database schema must use a Mermaid diagram and must show foreign key relationships clearly.
- Cost projections must use real, current pricing — search if uncertain.
- The document must be self-contained — a developer joining the team should understand the full architecture from this document alone, without needing to ask questions.
- Target length: 300-500 lines of Markdown.

5.3 Understanding the Prompt

A few notes on the key sections — read these once when you're first learning the prompt, then you won't need them again.

Stack Selection — No stack is prescribed. Rather than locking Claude into specific technologies, you're giving it the information it needs to make good choices for your product. A mobile app gets a different stack than a web dashboard. A healthcare product gets HIPAA-aware choices. Claude works this out from your research — which is why the research has to be good before you run this.

Section 2 (Key Architectural Decisions) — This section only appears if your product has something genuinely non-obvious under the hood. A simple CRUD app probably skips it. A product that needs real-time sync, multi-provider AI fallback, or an unusual data model will have something worth capturing here. If Claude includes it, read it carefully — it's explaining a choice that will affect everything downstream.

Section 3 (Infrastructure / Database Schema) — The Mermaid diagram is the most concrete output in the whole document. Even if you can't read code, you can look at a diagram of boxes and arrows and understand what data your product is tracking and how it connects. If the diagram looks wrong for what you're building, that's a signal worth acting on before you write any code.

Section 6 (Cost Projections) — Claude is instructed to search for current pricing, not estimate it. Check the numbers against the actual pricing pages for the services it recommended. The per-unit breakdown (cost per AI call, cost per email, etc.) is particularly useful when you're deciding on a pricing model.

Section 10 (Deployment Checklist) — You won't need this on day one, but you'll be glad it exists when you're prepping to launch.

Budget and team size placeholders — The {{monthly_budget}} and {{team_size}} values genuinely affect what Claude recommends. A solo developer on a $200/month budget gets different infrastructure choices than a two-person team with $800/month. Set these to reflect what you're actually working with.

5.4 Running the Prompt

Copy the prompt from Section 5.2. Fill in the three placeholders, then paste it into the Cowork input area — in Cowork it looks slightly different from a regular chat, but it works the same way. Select your model (I'm on Claude Sonnet 4.6 — the default) and hit Enter.

Don't paste your research document. You don't need to. Claude can see it already because it's in the folder you selected. Watch the output — you'll see Claude acknowledge it's found the document and then start building a task list for itself:

• Search current pricing for services
• Design the full tech stack
• Write the technical overview
• Save it to the workspace

Then it runs. This takes a few minutes. Walk away. Get water. Let it work.

6. Reading the Output (~15:30)

6.1 What Claude Figures Out On Its Own

This is the part that genuinely impressed me the first time I ran this. I gave Claude a prompt and a market research document — and it came back having made decisions I would have made myself.

For Nurturo, it figured out:

• Mobile-first: From the research, it correctly identified that all competitors are mobile apps. So it recommended React Native with Expo, targeting iOS and Android from a single codebase.
• Two-tier AI strategy: It thought through how AI features should be structured in the product without me specifying it.
• Vendor recommendations with rationale: It didn't just say "use Postgres" — it explained why Postgres made sense for this use case.
• Cost projections with free tier awareness: It went through each service in the stack and identified how much it costs at different scale levels. At 2,000 users, the projected monthly cost was around $420. That's a real number I can plan around.

You don't need to have a strong technical background to get value from this document. But having some sense of what good architecture looks like helps you know whether to push back on any of its choices. If something in the stack doesn't make sense for your project — trust your instincts and ask Claude to reconsider.

6.2 Highlights from the Nurturo Technical Document

Here's what came back for my app, so you know the kind of output to expect for yours:

Mobile framework: React Native with Expo (iOS and Android)

Backend API: NestJS (a Node.js framework) — structured, maintainable for a solo dev

Database: PostgreSQL with Upstash Redis for caching; BullMQ for job queues

Authentication: Clerk — handles auth so you don't have to build it from scratch

Email: Resend — modern, affordable, solid free tier

Hosting: Railway — $20/month for pro, very developer-friendly

Monitoring: Sentry (free tier) and PostHog for analytics (1 million events/month free)

AI integration: OpenAI for the AI features — notably, even though Claude is doing the research and drafting, it recommended OpenAI for the AI features in the product. It chose what it thought was best for the job. That's what I want from a good prompt.

Free tier summary: Almost every service in the stack has a meaningful free tier. At the stage where you're building and testing, your infrastructure costs should be close to zero. Claude called that out explicitly in the document.

6.3 The Architecture Diagrams

One of the things I didn't fully anticipate: Claude also produced a text-based architectural diagram of the database schema — tables, relationships, key fields. Before we've written any code. That kind of early-stage architectural clarity is exactly why the planning phase exists.

This whole document is what you'd eventually hand to a developer or an agency and say: "Build this." It tells them what the thing is, what it's built on, how it's hosted, what it costs to run, and how to set it up. And you produced it in about 20 minutes, without having to be a software architect yourself.

6.4 Where It Lives

Claude writes the document directly into your Cowork folder. Not in the chat. Not in a clipboard you have to paste somewhere. In the folder. Go open Obsidian and you'll find a new file called App - [AppName] - Technical.md. Open it, let it render, and read through it.

This is why I keep telling you to use Obsidian — or at least a notes tool with a local file path. Claude is writing directly to your file system. That's not just convenient; it's building a habit of having your planning documents live with your project, not scattered across chat windows you'll never find again.

7. Try It Yourself

Exercise 1: Name Your App

What to do: Use the naming prompt structure from Section 2 to generate app name candidates with Claude. Answer its clarifying questions. Pick your top two candidates. Then do the three validation checks: Google search, domain availability, trademark check (USPTO for US — check your local equivalent for other jurisdictions).

A nudge if you're stuck: If no name feels right after two rounds with Claude, try giving it a specific constraint — like "give me names that are one or two syllables, easy to spell, and that work in English-speaking markets." Sometimes narrowing the brief helps.

How you'll know it's working: You have a name you can say out loud without cringing, the .app or .com domain is available, and nobody has a trademark on it.

Exercise 2: Set Up Cowork and Run the Technical Document Prompt

What to do: Open Claude Desktop, go to the Cowork tab, select the folder where your research documents are saved. Copy the prompt from Section 5.2 of these notes, fill in the three placeholders — {{product_name}}, {{monthly_budget}}, and {{team_size}} — then paste it into Cowork and run it.

A nudge if you're stuck: If Cowork can't see your research document, double-check the folder you selected. The file needs to be inside the selected folder — not in a subfolder. Move it if necessary.

How you'll know it's working: Claude will acknowledge finding your market research document before it starts building. You'll see it referencing the correct file name in its output. When it finishes, a new App - [AppName] - Technical.md file should appear in your folder.

Exercise 3: Read and React to the Output

What to do: Open the technical document Claude produced. Read the executive summary and the stack section. Note any decisions you'd push back on — things that feel wrong for your project. If anything needs revisiting, go back to Cowork and ask Claude to reconsider specific choices with a reason.

What this is practising: Working with AI output critically — not just accepting the first draft, but knowing when to iterate.

8. You Should Be Able to Do This Now

Here's what you can put together with what we just covered:

• Use Claude as a naming partner — generating candidates, evaluating them with your own judgment, and validating before committing
• Set up Claude's Cowork tab and connect it to a project folder
• Use a structured prompt to generate a full technical architecture document grounded in your market research

Check Yourself

• [ ] My app has a name — validated on domain availability and trademark
• [ ] My project files are renamed consistently using that name
• [ ] I've set up Cowork with the correct folder
• [ ] I've run the technical document prompt and Claude produced the output
• [ ] The technical document is saved in my Obsidian folder and I've read through it
• [ ] I understand the basic shape of the stack Claude recommended (even if I can't explain every piece of it yet)

If Something's Not Working

The Short Version

Here's what I want you to walk away with:

• Name your app before you generate any documents: The name anchors your file naming, your prompts, and your identity as a product. Get it done and validate it before going further.
• Cowork is not the same as a regular Claude chat: It has file access. Use it for document generation. Use regular chat for conversation.
• The technical document is your architecture blueprint: Stack, hosting, cost projections, environment setup — all of it grounded in your research, produced before you write any code.
• Claude makes real architectural decisions: It doesn't just produce boilerplate. If the research is good, the document will reflect what your actual product needs. Read it critically and push back where needed.
• What you can do now: Generate a professional-grade technical overview for any product idea — in about 20 minutes, with no prior architecture experience required.

Quick Reference

Technical Document Prompt

The full prompt is in Section 5.2. Fill in before running:

• {{product_name}} — your app name (e.g. Nurturo)
• {{monthly_budget}} — your infrastructure budget (e.g. $500)
• {{team_size}} — how many people are building (e.g. 2-3 developers)

Naming Prompt Template

Based on the research and the sensitivity of what the name can imply, 
can you suggest names for my app? For context, here's a quote from 
a real user review I found: [paste a relevant review quote].

If you need any clarity before suggesting names, ask me first.

Name Validation Checklist

1. Google search — is anyone prominent using this name?
2. Domain check — is .app or .com available? (Namecheap, Google Domains)
3. Trademark search — USPTO (us) or your local equivalent

Cowork Setup Steps

1. Open Claude Desktop (not the browser version)
2. Click the Cowork tab at the top
3. Select folder → navigate to your project documents folder
4. Confirm your research file is visible in the sidebar
5. Paste your prompt and run

File Naming Convention (What I Use)

[AppName] Market Research.md
[AppName] Market Review.md
App - [AppName] - Technical.md     ← produced this lesson
App - [AppName] - UX.md            ← next lesson
App - [AppName] - Stakeholder.md   ← coming up
App - [AppName] - GTM.md           ← coming up

Resources

Tools Used

• Claude Desktop — required for Cowork tab and file writing
• Obsidian — note storage and file management (any tool with a local path works)
• Namecheap — domain availability checks
• USPTO TESS — US trademark search (free)

Technologies Claude Recommended for Nurturo

• React Native + Expo — cross-platform mobile framework
• NestJS — Node.js backend framework
• Railway — hosting platform
• Clerk — authentication
• Resend — transactional email
• PostHog — product analytics (generous free tier)
• Sentry — error monitoring (free tier available)

Questions I Get Asked

Q: Do I have to use the stack Claude recommended?

Not at all. Claude is recommending based on what it infers from your research. If you already know you want to build with a specific framework — because you know it, or because the team you're working with uses it — go with that. Update the technical document to reflect your actual choices. The document is yours. Claude's recommendations are a starting point, not a mandate.

Q: I'm not technical. Do I actually need to understand the technical document?

You need to understand it enough to be able to hand it to someone who is technical and have them say it makes sense. You don't need to know how to implement React Native — but you should understand that "mobile-first using React Native" means one codebase for both iOS and Android. Big-picture literacy is what you're going for. The module will get more technical as we move into coding, but by then you'll have a lot more context under your belt.

Q: Can I just use the browser version of Claude for this?

For the naming conversation — yes. For generating the technical document via Cowork — no. Cowork is only available in Claude Desktop. If you try to generate this in a regular chat by pasting your research document, you'll get a similar output, but it won't be saved to your folder automatically. You'll have to copy-paste it yourself. It's not a disaster, but it's more work and it breaks the workflow we're building toward.

Q: How do I know I'm ready for the next lesson?

The technical document is in your Obsidian folder, you've read through it, and you have a name you've validated. That's it. Move on.

💬 Stuck? Come Talk to Us

Glossary

Cowork: A tab in Claude Desktop that connects Claude to a folder on your computer, allowing it to read and write files directly. Not available in the browser version of Claude. (first used this lesson — Module 2, Lesson 3)

React Native: A framework for building mobile apps that run on both iOS and Android from a single codebase. Used with Expo for a more managed, developer-friendly setup. (introduced this lesson — Module 2, Lesson 3)

Expo: A toolset built on top of React Native that simplifies building, testing, and deploying mobile apps without needing to manage native iOS/Android build tools directly. (introduced this lesson — Module 2, Lesson 3)

NestJS: A Node.js framework for building backend APIs. Structured and opinionated — which is a good thing when you're building solo, because it makes the architecture more predictable. (introduced this lesson — Module 2, Lesson 3)

Technical Document: A planning document that describes the product's architecture — stack choices, infrastructure, security, API design, cost projections, and environment setup. Lives with the codebase. Does not contain any code itself. (first produced this lesson — Module 2, Lesson 3)

Trademark: A legal registration that gives exclusive rights to use a name or mark in commerce. Check before committing to a product name. In the US, search via USPTO TESS (free). (introduced this lesson — Module 2, Lesson 3)

.app domain: A top-level domain (.app) commonly used for software products and mobile apps. Managed by Google, HTTPS required by default. Generally more available and more relevant than .com for new apps. (introduced this lesson — Module 2, Lesson 3)