Week 32 of 32
Ship and roadmap
Deploy + Demo + Roadmap
Ship the prototype with a demo walkthrough, deployment artifact, and a prioritized v2 roadmap.
Lecture
The tool works. The editor accepts text. The scene navigator populates. The AI panel asks questions. Some features are rough. Some are missing. Some edge cases haven't been handled. That's fine. This week isn't about perfection — it's about shipping. Shipping means the tool leaves your machine and becomes something another person could use, evaluate, or build on. It means writing a demo script that walks through the tool's capabilities in two minutes. It means producing a v2 roadmap that documents the features you'd build next — not as aspiration, but as a technical record of decisions made and deferred. And it means declaring the tool done, the same way you declared the screenplay done in Week 28: not because nothing remains to improve, but because the work has reached a state worth sharing. The discipline of shipping is the discipline of completion. You've practiced it once already — with a hundred-page screenplay. Now you practice it again, with a piece of software. The skill transfers. It always transfers.
What "done enough" means. A prototype is not a product. It doesn't need to handle every edge case, support every browser, survive adversarial input, or scale to a thousand users. A prototype needs to demonstrate the idea — to show, through a working example, that the concept is viable and the core interaction is valuable. Your tool's "done enough" threshold is defined by the success criteria in your Week 29 PRD. If the criteria are met — if a writer can draft, navigate by scene, and receive diagnostic questions — the prototype has achieved its purpose. Everything beyond the success criteria is improvement, not completion.
Three tests for "done enough":
Test 1: The stranger test. Could someone who didn't build the tool open it, understand what it does, and use its core features within five minutes — without you in the room explaining? If yes, the tool is communicable. If no, the tool needs either a clearer interface or a brief walkthrough (the demo script). Most prototypes fail the stranger test the first time, which is why the demo script exists: it bridges the gap between the builder's mental model and the user's experience.
Test 2: The value test. Would you — the person who built it, who has access to every other screenwriting tool on the market — actually use this tool during your next screenplay? Not out of loyalty to your own creation. Because it does something genuinely useful that your other tools don't. If yes, the tool has value. If no, identify the one feature that would make you use it, and ask whether that feature is achievable before the week ends. Sometimes the gap between "wouldn't use it" and "would use it" is one small addition — a keyboard shortcut, a visual improvement, a data persistence fix.
Test 3: The conversation test. Could you show this tool to another screenwriter and have a substantive conversation about it? Not "look what I made" (that's show-and-tell). "Here's the problem this solves, here's how it solves it, here's what I'd build next" (that's a product conversation). The demo script and the v2 roadmap prepare you for this conversation. They transform the prototype from a personal project into a product idea with a trajectory.
Deployment options. "Deploy" sounds formal. For a prototype, it means making the tool accessible outside your local development environment. The simplest options:
Option A: Static file sharing. If your tool is a single HTML file (the recommended approach from Week 30), deployment is trivial: upload the file to any static hosting service. GitHub Pages is free — create a repository, upload the HTML file, enable Pages in the repository settings, and you have a live URL. Netlify and Vercel offer similar free-tier static hosting with drag-and-drop deployment. The tool is now accessible to anyone with the link. Note: if the tool includes a hardcoded API key for the AI panel, do NOT deploy it publicly — the key will be visible in the source code. Either remove the AI panel from the deployed version (keep it local-only), implement the clipboard fallback for the public version, or add a simple server-side proxy to protect the key (more complex, but achievable with AI-assisted coding).
Option B: Downloadable file. If deployment to a hosting service isn't feasible or if the tool includes sensitive configuration (API keys), distribute the tool as a downloadable HTML file. Upload it to a file-sharing service, attach it to an email, or include it in a GitHub repository as a download. The user opens the file in their browser locally. No hosting needed. No API key exposure.
Option C: Screen recording. If the tool can't be deployed or shared as a file (technical issues, incomplete features, platform dependencies), create a screen recording of the tool in action. A two-minute video showing the editor, the scene navigator, and the AI panel working with a real screenplay is a valid demo deliverable — it proves the tool works even if the tool itself isn't distributable. This is the fallback, not the goal. But a recorded demo of a working prototype is better than a deployed version that crashes.
The demo script. The demo script is a written walkthrough — a step-by-step document that describes how to use the tool, what each feature does, and what the user should expect to see. It's not a user manual (too long) or a sales pitch (too vague). It's a guided tour — the sequence of actions a first-time user should take to experience the tool's core value in under three minutes.
The demo script format: a numbered list of steps, each one containing an action ("Type a scene heading: INT. KITCHEN - NIGHT") and an expected result ("The heading appears in the sidebar under SCENES"). The script should cover: opening the tool, typing or pasting screenplay text, observing the scene navigator populate, clicking a scene to navigate, invoking the AI diagnostic panel (or the clipboard fallback), and reading the resulting questions. Total: 8–12 steps. Each step is one sentence of action and one sentence of result. The demo script doubles as a test script — if you can execute every step and see the expected result, the tool is working.
The v2 roadmap. The roadmap is not a wish list. It's a prioritized document that records three categories of future work:
Category 1: Known bugs. Things that are broken or unreliable in the current prototype. The scroll offset that's slightly wrong. The scene detection that misses headings with unusual formatting. The localStorage that occasionally drops content. Each bug is one sentence: what's broken, under what conditions, and (if known) why. This section is honest — it's the version notes of the prototype, the same way the screenplay had version notes in Week 28.
Category 2: Deferred features. Features from the prioritized backlog (Week 29) that didn't make it into the MVP. Each feature is listed with its original priority ranking and a brief note on why it was deferred (scope, complexity, time) and what it would take to implement. This section tells a future builder (you, or someone else) what the product wants to become.
Category 3: Discovered features. New ideas that emerged during the build — things you realized the tool needed that weren't in the original PRD. These are the build's surprises, the same way the draft produced surprises during Weeks 16–21. A feature you thought of on Day 4 of the build sprint, when you realized the scene navigator would be more useful with a word-count-per-scene display. A UX improvement you noticed during testing, when you found yourself wanting a keyboard shortcut to jump between scenes. Discovered features are often the most valuable items on the roadmap because they come from direct experience with the tool rather than pre-build speculation.
Core Reading
This is the final week. No new screenplays, no tool reviews. Use all available time for deployment, demo, and roadmap. If you finish early, do something the curriculum hasn't asked you to do: open your finished screenplay (the one from Week 28, not the tool) and read the first page. Just the first page. You wrote that page twenty weeks ago and revised it across six weeks of passes. It's the best page you've ever written. Read it one more time. Then close the file.
Writing Exercise
Deliverable: Deployed/exported app + demo script + v2 roadmap.
Constraints: Produce three artifacts:
(a) Deployed or exported app. Make the tool accessible outside your local development environment using one of the three deployment options: static hosting (GitHub Pages, Netlify, Vercel), downloadable file, or screen recording. If deploying to a live URL, verify the tool works in at least two browsers (Chrome + one other). If distributing as a file, verify it opens cleanly on a second device. If creating a screen recording, keep it under three minutes and demonstrate all core features.
(b) Demo script (1 page). A numbered walkthrough — 8–12 steps, each with an action and an expected result. The demo script should cover the full core workflow: open, type/paste, navigate by scene, invoke the diagnostic panel, read questions. The script doubles as a test: executing every step and seeing the expected result confirms the tool is working. Write the demo script for someone who has never seen the tool — not for yourself.
(c) V2 roadmap (1–2 pages). Three sections: known bugs (what's broken and why), deferred features (from the backlog, with priority and effort estimates), and discovered features (new ideas from the build process). Each item is one to three sentences. The roadmap should be honest about the prototype's limitations and specific about what the next phase of work would produce.
Quality bar: The deployed tool must be usable — the demo script's steps must produce the expected results when executed by someone other than the builder (even if that someone is you pretending to be a stranger). The demo script must be clear enough to follow without prior knowledge of the tool. The roadmap must contain at least two items in each category (bugs, deferred, discovered). The whole package — tool, demo, roadmap — should communicate: "This is what exists, this is how it works, this is where it goes next."
Estimated time: 6–10 hours (final bug fixes and polish: 2–3 hours; deployment: 1–2 hours; demo script: 1–2 hours; roadmap: 1–2 hours; testing: 1 hour).
AI Workshop
The final AI collaboration: a pre-ship review. Use the prompt below to get a last-look evaluation of the prototype's code, the demo script's clarity, and the roadmap's prioritization. This is the product equivalent of the Final Reader test from Week 28 — an external perspective on the work before it ships.
Student Self-Check
Editorial Tip
You've now shipped two things in thirty-two weeks: a feature screenplay and a software prototype. Both required the same core discipline: defining a scope, building within constraints, revising through passes, knowing when to stop, and letting the work be seen by others. The screenplay taught you how stories work from the inside — the architecture of beats, turns, arcs, and images. The prototype taught you how tools work from the inside — the architecture of features, interactions, constraints, and trade-offs. Both experiences make you better at the other. A writer who understands tools builds better workflows. A builder who understands stories designs better products. The intersection is where the most interesting work happens — tools that respect the creative process because they were designed by someone who has lived it.
Journal Prompt
Thirty-two weeks. A feature screenplay, drafted and revised to submission-ready quality. A software prototype, built from spec to ship in four weeks. A portfolio of structural documents, diagnostic tools, and revision strategies you can carry into every future project. Write the last journal entry of the curriculum — not about the screenplay, not about the tool, but about the process. What is the single most important thing you learned about how you work? Not a craft principle — a self-knowledge principle. The thing you now know about your own creative process that you didn't know in Week 1. Maybe it's about your relationship to revision (you resist it or you love it too much). Maybe it's about your relationship to structure (you need it as scaffolding or you fight it as constraint). Maybe it's about your relationship to completion (you finish things easily or you need external deadlines and phase gates to get there). Name the thing. Write it down. Carry it forward. It's more valuable than the screenplay or the tool — because the screenplay is one story, and the tool is one product, but the self-knowledge applies to everything you make from here on.
Week Summary
By the end of this week you should have:
• Deployed, exported, or recorded the prototype — making it accessible beyond your machine
• Written a demo script (8–12 steps) that walks a first-time user through the core workflow
• Produced a v2 roadmap with known bugs, deferred features, and discovered features
• Verified the prototype against the PRD's success criteria
• Run the pre-ship review prompt and addressed the highest-priority fix
• Tested the tool with your finished screenplay one final time
And across thirty-two weeks, you have built:
• A complete, human-written feature screenplay (80–125 pages), revised through four structural passes and polished to submission standard
• A logline, one-page synopsis, and two-minute verbal pitch
• A portfolio of structural documents: concept doc, character dossier, antagonist plan, world rules, promise map, 8-sequence outline, scene list, change list, and Disagreement Log
• A working screenwriting tool prototype with scene navigation and AI-assisted diagnostics
• Twenty-eight weeks of film and screenplay analysis, building a vocabulary for cinema craft that will inform every script you write
• The knowledge of how to do all of this again — faster, sharper, with the accumulated instinct of someone who has finished the thing once already
Required artifacts:
• A working prototype (even minimal) — deployed, exported, or recorded
• A demo script showing the tool's core workflow
• A v2 roadmap documenting bugs, deferred features, and discovered features
If you're behind: The prototype must demonstrate at least one feature that works — even if it's only the scene navigator without the AI panel. A demo showing a working editor with scene detection is a valid deliverable. The AI panel can be documented as a v2 feature in the roadmap. Ship what exists. A deployed prototype with one working feature is better than a local prototype with three half-working features.
The real deliverable of this entire course is the screenplay from Week 28. The app is a bonus. If the screenplay exists as a finished, proofread PDF with a logline and synopsis, the curriculum has succeeded — regardless of the prototype's state. The tool is proof that the writer can build. The screenplay is proof that the writer can write. Both are valuable. The screenplay is essential.
What comes next: Submit the screenplay to contests, festivals, and representation queries. Use the logline and synopsis as your front door. Let the script be read. Start collecting feedback — from human readers, not just AI. When the feedback accumulates into a pattern, consider a third draft. Between drafts, start developing your next premise. The curriculum's tools — the premise machine, the character architecture, the escalation ladder, the scene engine, the revision passes — are yours to use on every future project. The process doesn't end here. It starts again, with everything you've learned, on a blank page.