Start Building

Lesson 15: Portfolio case study and postmortem

Shipping a game is the hard part. Presenting how you shipped it is the part that turns your work into career leverage.

This lesson helps you turn your Unity 2026 release into a portfolio-ready case study: a narrative that explains what you built, how you made decisions, what you measured, and what you would do differently next time.

You are not writing marketing fluff. You are building trust with evidence.

Lesson Objective

By the end of this lesson you will:

  1. Create a metrics story that connects your decisions to outcomes
  2. Write an honest postmortem that includes wins, tradeoffs, and what you would change
  3. Produce a screenshot evidence set that supports your claims
  4. Generate a portfolio-ready outline you can reuse for your next project

Why this matters now

Recruiters and collaborators are rarely impressed by “we worked hard.” They want to see:

  • What you decided
  • Why you decided it
  • What happened when you tried
  • What you learned after real testing and launch reality

This is the final packaging step that makes your process visible.

Step-by-step workflow

Step 1: Build your “evidence list” (what you can show)

Before you write anything, collect proof. A strong case study usually has 8 to 14 artifacts:

  • 2 to 3 screenshots that show gameplay readability (HUD and moment clarity)
  • 2 to 3 screenshots that show progression (menus, upgrades, checkpoints, systems)
  • 2 to 3 screenshots that show technical discipline (debug overlay, profiler view, UI state)
  • 1 short clip or gif capture (optional, but powerful)
  • 1 “release day” artifact (store page preview, build version string, or patch note snippet)

If you are missing screenshots, this is a sign you should capture them during the next playtest or update cycle, not after.

Step 2: Write a metrics story that does not hide behind vanity numbers

Pick metrics you can explain in plain language.

Start with a simple template you can paste into your notes:

{
  "project": "Unity 2026 indie game",
  "builds": [
    { "date": "2026-03-25", "platform": "Windows", "smokeTest": "pass", "version": "1.0.0" }
  ],
  "storeSignals": {
    "wishlists": 0,
    "conversionRate": 0.0,
    "refundRate": 0.0
  },
  "playtesting": {
    "sessions": 0,
    "topFrictionArea": "UI clarity / readability",
    "fixesShipped": 0
  },
  "performance": {
    "targetFPS": 60,
    "peakCPUms": 0.0,
    "peakMemoryMB": 0
  }
}

Replace 0 with your real values. If you do not have store metrics yet, use what you do have: playtest counts, bug triage categories, performance targets, and “time-to-fix” patterns.

Pro tip: every number should map to a decision.

Example mapping:

  • “We changed input buffering because testers missed certain actions.”
  • “We reduced particle counts because profiling showed memory spikes during stress scenes.”
  • “We simplified menus because the first 30-minute dropoff clustered around onboarding confusion.”

Step 3: Write the postmortem in three honest sections

Structure your postmortem like a lab report:

  1. What worked (and why)
  2. What struggled (and what your data said)
  3. What you would change next (and what you would test)

Your tone matters:

  • Specific beats generic
  • Tradeoffs beat excuses
  • Lessons learned beat apologies

Keep each section to 150 to 250 words so it is readable.

Step 4: Turn your story into a recruiter-friendly portfolio outline

Use this outline:

  1. One-paragraph hook: what the project is and what you are proud of
  2. Scope summary: 5 bullets that explain content and goals
  3. “Decision log”: 3 to 5 decisions with the reason and the outcome
  4. Evidence: screenshots you selected and what each one proves
  5. Postmortem: the three sections from Step 3
  6. Next iteration: what you would do if you had 2 more months

This outline should fit on one page in your first draft.

Step 5: Tie your portfolio back to launch discipline

Your case study should acknowledge release reality:

  • smoke tests and build pipeline decisions
  • store page clarity work
  • iteration cadence and how you avoided last-minute chaos

If you followed the course workflow, you can cross-reference:

  • Lesson 13: build pipeline and platform checks
  • Lesson 14: store page assets and launch checklist

That connection makes your story coherent.

Mini challenge (30 minutes)

Create a “Portfolio Draft Pack” folder (even if it is just a doc):

  1. hook.txt (80 to 120 words)
  2. decision-log.md (3 decisions, each with outcome)
  3. postmortem.md (3 sections, each 150 to 250 words)
  4. evidence-list.md (8 to 14 items with a one-line “what it proves” note)

When you are done, do one fast test:

Can a new teammate skim your evidence list and understand your process without reading every paragraph?

Pro Tips (advanced portfolio polish)

  1. Separate “learning” from “results”

    • Learning: what you understood about players, pipeline, or systems
    • Results: what shipped and what changed in the next iteration

  2. Include one “bad news” moment

    • Not to be dramatic, but to show you can handle reality and still ship.

  3. Keep your screenshots honest

    • Do not show UI moments that only exist in a dev branch unless you explain the difference.

  4. Use consistent naming for artifacts

    • Your future self will thank you when you update your portfolio for your next project.

Troubleshooting

“I do not have real metrics yet”

Use process metrics:

  • number of playtest sessions
  • bug triage categories and counts
  • time-to-fix for your top recurring issues
  • performance target adherence (even if you cannot measure store conversion yet)

Recruiters still understand iterative development when you explain it clearly.

“My postmortem sounds generic”

Fix the “because” sentences:

  • Replace “We optimized performance” with “We optimized performance because profiling showed X during scene Y and testers reported Z.”

“My screenshots do not support my claims”

Re-select screenshots using this rule:

Every claim needs at least one visual artifact or one measurable outcome.

Common mistakes to avoid

  • Listing tasks instead of decisions
  • Including too many screenshots with no explanation of what to look for
  • Hiding tradeoffs that you learned the hard way
  • Writing a postmortem before you capture evidence

FAQ

How long should a portfolio case study be

Aim for 800 to 1,200 words in your first draft. You can shorten later by removing repeated context and keeping the decision log and evidence sections tight.

Should I include exact numbers if they are imperfect

Include what you can defend. If numbers are estimates, say so. If you cannot measure something yet, use process metrics and explain the limitation.

What screenshots matter most

Screenshots that show readability and decision evidence. Especially: HUD clarity, onboarding or menu flow, and one technical proof image (debug/perf).

Recap

You created a portfolio case study workflow that turns your Unity 2026 release into a clear story:

  • Evidence list for screenshots and proof
  • Metrics story that connects decisions to outcomes
  • Honest postmortem with wins, struggles, and next changes
  • A reusable outline for future projects

Next lesson teaser

With the portfolio draft ready, your next “lesson” is to publish it and iterate:

  • update the case study once you have more post-launch data
  • refine your evidence list based on feedback from viewers

Bookmark and share

If you found this useful, bookmark the lesson for your next release and share it with your team so everyone writes stronger postmortems and better portfolio stories.