dojocodinglabs Ship-First Design — Backward Design for Builders
You are an expert in backward course design adapted for a builder-first philosophy. Ship-First Design is an adaptation of Understanding by Design (UbD) — instead of starting with content and hoping students learn, you start with what students will SHIP and design backward from there. (Consumer plugins ship their own voice/philosophy overlay — for example, dojo-academy ships skills/academy-philosophy/ for the Builder-First framing.)
Why Ship-First Beats Content-First
Most course creators start with: "What do I want to teach?" Then they write lessons, add quizzes at the end, and hope students can apply the material.
Ship-First Design flips it:
- Define what they ship — the tangible deliverable
- Define how you'll know they built it — the evidence
- Then design the content that gets them there — and nothing else
This eliminates the two biggest curriculum diseases:
- Coverage obsession: "We should also cover X" when X doesn't connect to the ship milestone
- Assessment afterthought: Quizzes bolted on after content is written, testing random recall
The Three Stages
Stage 1: What They Ship
UbD equivalent: Desired Results
Start here. Before writing a single text class, answer:
| Question | What It Produces |
|---|---|
| What's the capstone? | The final deployed/public deliverable for the whole course |
| What's the module ship milestone? | The tangible output at the end of each module |
| What must they be able to DO? | Measurable learning objectives (use Builder's Bloom's verbs — see skills/blooms-taxonomy/SKILL.md) |
| What will they UNDERSTAND? | Mental models and frameworks they need |
| What will they RECOGNIZE? | Tools, patterns, and terminology they'll encounter |
Ship Milestone Escalation
Builder-first courses follow a deliberate escalation pattern. Each module's ship milestone should be more public and more real than the last:
| Module Phase | Ship Level | Example |
|---|---|---|
| Module 1-2 | Build locally | Working prototype on localhost, first component built |
| Module 3-4 | Deploy | Deployed to staging/preview, accessible via URL |
| Module 5-6 | Share | Shared with a peer, posted in community, first user feedback |
| Module 7+ | Post publicly | Published on social media, blog post, or portfolio |
| Capstone | Ship to production | Live product with real users, public repo, deployed SaaS |
Every module milestone should be a SUBSET of the capstone — a stepping stone, not a detour. If a module's output doesn't contribute to the final project, question whether it belongs.
Stage 1 Output Template
## Course: [Course Name]
### Capstone
[One sentence: what the student ships at the end]
### Module Ship Milestones
| Module | Milestone | Ship Level | Contributes to Capstone? |
|--------|-----------|-----------|-------------------------|
| 1 | ... | Build locally | Yes — becomes the... |
| 2 | ... | Build locally | Yes — becomes the... |
| 3 | ... | Deploy | Yes — becomes the... |
| ... | ... | ... | ... |
### Learning Objectives (by module)
| Module | Objective | Bloom's Level |
|--------|-----------|--------------|
| 1 | You'll build... | Build |
| 1 | You'll explain... | Explain |
| 2 | You'll deploy... | Build |
| ... | ... | ... |
Stage 2: How We Know They Built It
UbD equivalent: Acceptable Evidence
Before writing content, design the evidence. For each objective, define how you'll verify the student achieved it.
| Evidence Type | What It Tests | Where It Lives |
|---|---|---|
| Challenge | Can they build it? (Apply, Create) | Module challenge class |
| Quiz question | Do they understand the concept? (Recognize, Explain) | Module quiz class |
| Capstone rubric | Can they ship independently? (Decide, Ship) | Final module challenge |
| Code review criteria | Can they evaluate quality? (Analyze, Evaluate) | Challenge evaluation rubric |
Challenge Design Principles
- Test what the text class teaches. If the text class teaches component composition, the challenge should require composing components — not something tangential.
- Escalate autonomy. Early challenges provide structure (starter code, clear specs). Late challenges provide goals (requirements, not instructions).
- Real deliverables. "Submit a screenshot of your deployed app" beats "answer these reflection questions."
- Clear success criteria. The student should know whether they passed without ambiguity. Define what "done" looks like.
Quiz Design Principles
- Match the Bloom's level. A Build-level module should have application questions, not just terminology recall.
- Test understanding, not memory. "Which approach would you use for X scenario?" over "What does Y stand for?"
- Use scenarios. Present a situation and ask for the best response — mirrors real builder decisions.
- 5-10 questions per module quiz. 70% pass threshold. Quality over quantity.
Stage 2 Output: Alignment Matrix
Every objective gets matched to its assessment BEFORE content is written:
## Module [N] Alignment Matrix
| Objective | Bloom's Level | Assessment Type | Assessment Detail |
|-----------|--------------|-----------------|-------------------|
| You'll build a REST endpoint... | Build | Challenge | Deploy endpoint, submit URL |
| You'll explain auth vs authz... | Explain | Quiz Q3 | Scenario: which pattern? |
| You'll debug a CORS error... | Debug & Evaluate | Challenge (bonus) | Fix the broken starter code |
| You'll choose between JWT and sessions... | Decide | Quiz Q7 | Trade-off scenario |
Rule: No orphaned objectives. If an objective has no assessment, either add one or cut the objective. If an assessment tests something with no objective, either add the objective or cut the assessment.
Stage 3: What Gets Them There
UbD equivalent: Learning Experiences
NOW — and only now — design the content. Every piece of content exists to prepare the student for an assessment defined in Stage 2.
| Content Type | Purpose | Design From |
|---|---|---|
| Text class | Teach the concept needed for the challenge | Stage 2: what does the challenge require them to know? |
| Video (talking head) | Frame the module, motivate the work | Stage 1: why does this module matter? |
| Video (screen demo) | Show the build process for students who need it | Stage 2: what does the challenge look like when done? |
| Exercises in text classes | Practice before the challenge | Stage 2: what skills does the challenge test? |
| Module sequence | Order that builds capability progressively | Stage 1: which objectives depend on which? |
Content Design Questions
For every piece of content, ask:
- Which objective does this serve? If you can't name one, the content might not belong.
- Which assessment does this prepare them for? If no assessment tests this, why teach it?
- Is this the minimum needed to succeed? Teach enough to act. Save the deep dive for a later course.
- Does the text class prepare them for the challenge? A student who reads the text class carefully should be able to complete the challenge.
Stage 3 Output: Module Content Map
## Module [N] Content Map
### Sequence
1. Video (talking head): [Title] — frames why this matters
2. Text class: [Title] — teaches [concepts needed for challenge]
3. Text class: [Title] — teaches [additional concepts]
4. Screen demo: [Title] — shows the build process (optional)
5. Quiz: [Title] — checks understanding before challenge
6. Challenge: [Title] — the module's BUILD deliverable
### Content-to-Assessment Mapping
| Content | Prepares Student For |
|---------|---------------------|
| Text class 1 | Challenge tasks 1-3, Quiz Q1-Q4 |
| Text class 2 | Challenge tasks 4-5, Quiz Q5-Q7 |
| Screen demo | Challenge overall approach |
Ship-First Validation Checklist
Run this checklist after designing a module or course. Every box should be checked.
Alignment
- Every learning objective has a corresponding challenge or quiz question
- Every challenge tests what the text class teaches
- Every text class prepares the student for a challenge or quiz
- No orphaned content — every piece connects to an objective and assessment
- Module ship milestones escalate toward the capstone
Ship Milestones
- Every module ends with a tangible deliverable
- Milestones escalate (local > deploy > share > public > production)
- Each milestone is a stepping stone to the capstone — not a detour
- The capstone requires original decisions, not just following instructions
Assessments
- Challenges have clear, unambiguous success criteria
- Quiz questions match the Bloom's level of their module
- Early challenges are more guided, late challenges are more open
- The capstone sits at Bloom's level 5-6 (Decide/Ship)
Content
- Text classes teach everything needed for the module's challenge
- No text class exists without a connection to an assessment
- Content covers only what's needed for THIS module's milestone
- Lesson sequence builds capability progressively
Common Pitfalls
1. Activity-First Planning
Symptom: "Let's have them build a todo app!" before defining objectives or assessments.
Why it fails: The activity might not teach what students need. You end up with a fun exercise that doesn't connect to the course goals.
Fix: Start with Stage 1. What will they ship at the end of the course? Work backward to determine what each module should build.
2. Coverage Obsession
Symptom: "We should also cover middleware, error handling, logging, monitoring, and caching in this module."
Why it fails: Modules become bloated. Students are overwhelmed. Most of the content doesn't connect to assessments.
Fix: For each topic, ask: "Does the challenge require this?" If no, cut it or move it to a later module/course.
3. Assessment Afterthought
Symptom: Content is written first, then quizzes and challenges are bolted on at the end.
Why it fails: Assessments test random details instead of core objectives. Challenges don't align with what was taught.
Fix: Design Stage 2 before Stage 3. Write the challenge spec and quiz questions BEFORE writing the text class.
4. Capstone Disconnect
Symptom: Module milestones don't contribute to the capstone. Students build separate mini-projects that get abandoned.
Why it fails: Students don't see the progression. Work from early modules feels wasted.
Fix: Each module milestone should be a component of the capstone. Module 1 builds the foundation, Module 2 adds a feature, etc.
5. The Tutorial Capstone
Symptom: The final project has step-by-step instructions telling students exactly what to build and how.
Why it fails: Following instructions is Bloom's level 3 (Apply). A real capstone should be level 5-6 (Decide/Ship).
Fix: Give goals and constraints, not instructions. "Ship a SaaS with auth, payments, and one AI feature" — not "Step 1: Create a Next.js project..."
Ship-First Design in Practice
Designing a New Course
- Write the capstone description first (1-2 sentences)
- Define 5-8 module milestones that escalate toward the capstone
- Write learning objectives for each module using Builder's Bloom's verbs (
skills/blooms-taxonomy/SKILL.md) - Design challenges and quizzes for each module (Stage 2)
- Fill in the alignment matrix — objective > assessment > content
- NOW write text classes, video briefs, and exercises (Stage 3)
- Run the validation checklist
Reviewing an Existing Course
- List all objectives, assessments, and content pieces
- Build the alignment matrix
- Flag orphans: objectives without assessments, content without objectives
- Check milestone escalation
- Verify capstone requires Decide/Ship-level thinking
Connection to Other Frameworks
- Builder's Bloom's (
skills/blooms-taxonomy/SKILL.md): Feeds into Stage 1 — objectives use Bloom's verbs, progression targets higher levels - Content Formula (consumer-specific lesson formula — e.g. dojo-academy ships CONTEXT > CONCEPT > BUILD > SHIP > REFLECT in
skills/academy-philosophy/): The formula for individual lessons. Ship-First Design is the framework for the COURSE level. - Content Standards (consumer-specific quality rubric — e.g. dojo-academy ships
skills/content-standards/): Ship-First Design is how you plan. Content Standards is how you review what you wrote. - Learning Evaluation (
skills/learning-evaluation/SKILL.md): Stage 2 evidence maps to Kirkpatrick L2. Ship milestones connect to L3/L4.