Create structured project post-mortems with what went well, improvements, action items, and lessons learned documentation.
The guide
After a project ends, the conclusions live in people's heads until someone writes them down. This tool takes the facts and observations you enter about a finished project and arranges them into a structured post-mortem document with fixed sections: what went well, improvements, action items, and lessons learned. The result is a document you can review and share instead of a blank page to format yourself. The surprise for most users is that the tool does not analyze anything. It does not judge your results, weigh causes, or score the project. The structure is the tool's work; the insight is yours.
A concrete input and expected output from the current implementation.
Input
Project: Aurora billing migration. Dates: May 4 to June 20, 2026. Team: 6 engineers. What went well: cutover had zero customer-facing downtime; launched on the planned date. Improvements: two billing IDs mismatched between databases, found during testing. Action items: add cross-database ID checks to the test suite.
Expected output
Project Post-Mortem: Aurora billing migration Dates: May 4 to June 20, 2026. Team: 6 engineers. What went well: cutover had zero customer-facing downtime; launched on the planned date. Improvements: two billing IDs mismatched between databases, found during testing. Action items: add cross-database ID checks to the test suite. Lessons learned:
The document mirrors the input exactly, with each entered note placed under its matching section heading. The lessons-learned section is left blank because the user entered nothing for it; the template only places content the user supplies, and an empty section shows the team which questions it skipped.
You enter the project name, dates, and participants, then add observations under the categories the template provides. Each entry is placed into the matching section of the document: what went well, improvements, action items, and lessons learned. The sections assemble in one consistent order, so the finished document reads the same from one project to the next and reviewers find the same information in the same place.
The template never calculates, compares, or interprets what you write. A note such as 'QA found the bug three days before launch' appears under improvements exactly as typed, with no severity rating or cause attached. Every sentence in the output is a sentence someone entered; the template's only contribution is where each entry appears and how the document is laid out.
No. It structures the reasons you already have; it does not read your project data, metrics, or history, so it cannot discover a cause nobody wrote down. If the team disagrees about what happened, the template documents both accounts rather than settling the question. Hold the discussion first, then record what the team concluded.
The tool runs entirely in the browser and nothing you type is uploaded anywhere. The document exists only on your machine, and you save or share it yourself. That matters when the notes are candid: the exported file, not the template, is what other people will eventually see.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Sent. Thank you.
