Module 2, Lesson 3: Generating the Technical Document

In this lesson, I'm picking up straight after the research phase. We've validated the market, we've confirmed the gap — now it's time to start turning that into actual product documents. And we're kicking that off with 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 your course resources. 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 Structure

Here's the shape of the technical document prompt:

Role: You are a senior technical architect for solopreneurs and lean teams.

Find: Look in the folder for the market research file for [AppName].

Task: Produce a comprehensive technical overview document in Markdown, saved as [AppName] Technical.md.

Input: The market research report already in the folder. The product name comes from the research filename — which is why naming your files correctly matters.

Product description: Infer from the market research. Don't ask — figure it out from what's there.

Product stack: Choose the best tools for this specific product. Think about the nature of the product — is it mobile-first? Web? Both? — and select the stack accordingly.

Constraints: Budget-conscious. Think generous free tiers wherever possible. Keep the stack lean. Think like a solo founder who has to actually maintain this, not like an enterprise CTO with a team of 20.

Depth level: Describe what things do, but don't go into implementation detail. We're writing a planning document, not a codebase. Claude has a tendency to start writing code if you don't reign it in — this constraint keeps it at architecture level.

Document structure to produce:

• Executive summary
• Architecture decisions and rationale
• Infrastructure and hosting setup
• Security and authentication approach
• API architecture overview
• Cost projections (with actual pricing, not guesses)
• Environment variables and configuration
• Development setup overview

Research and gap-filling: Search the web to verify current pricing for any services recommended. Cite sources. Don't make up numbers.

5.3 Running the Prompt

Copy the prompt from the prompt library. In Cowork, make sure your folder is selected. Paste the prompt into the 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 [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 technical document prompt from the prompt library, update the app name placeholder to your actual app name, 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 [AppName] Technical.mdfile 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

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
[AppName] Technical.md       ← produced this lesson
[AppName] UX.md              ← next lesson
[AppName] Stakeholder.md     ← coming up
[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)