Every experienced Drupal freelancer knows the ritual: six months after a launch, a prospective client asks for evidence of past work, and the freelancer goes digging through old tickets hoping to reconstruct what actually happened. What they find is always thinner than the project deserved — screenshots nobody took, decisions nobody wrote down, numbers nobody recorded. The fix is not better memory; it is capturing launch handoff evidence during the launch window itself, when the material exists and takes minutes to save. This article is the operational companion to what launch handoff evidence belongs in a Drupal portfolio — the parent defines what belongs in a portfolio, this article builds one launch’s worth of it in real time. The captured evidence pours naturally into the Drupal case study template, and half of it already lives inside a disciplined Drupal launch retrospective.
The method is a capture list of six artifacts, each tied to a moment in the launch window when it is cheapest to collect. None requires new tooling beyond a folder, a habit, and roughly an hour spread across two weeks. Where the evidence touches conformance claims, the captured material should reference recognized criteria rather than invented ones — the W3C WCAG guidelines are the standard anchor for anything accessibility-related, and naming the exact success criteria a launch met turns a vague claim into a checkable one.
Why After-The-Fact Evidence Always Fails
The asymmetry is simple: evidence is cheapest at the moment it is created and most expensive when it must be reconstructed. The accessibility audit performed during launch exists as a report, a spreadsheet, a few tickets — all alive and organized in that week. Six months later the report lives in a client’s systems, the tickets are closed and filtered out of default views, and the memory of what the numbers were has softened into superlatives. Reconstruction also introduces a quiet credibility problem: portfolio evidence assembled from memory tends to describe the launch that should have happened rather than the one that did, and experienced evaluators can smell the difference. Capturing during the launch avoids both costs, and it has a side effect worth mentioning — knowing that evidence will be kept changes behavior during the launch itself, nudging the team to actually run the checklist rather than intend to.
The Six Artifacts And Where Each Comes From
Each artifact below is tied to its capture moment. The list is deliberately short; a portfolio needs proof, not archives.
| Artifact | What goes in it | Capture moment |
|---|---|---|
| Definition snapshot | The agreed scope, roles, and definition of done, saved as written | Signing day — before work starts |
| Before evidence | Analytics, performance scores, and screenshots of the old site | Kickoff week, while the old site still runs |
| Build proof | Component screenshots, a short screen recording of the editor flow, architecture notes | During build reviews, not after |
| Launch record | Go-live checklist as executed, with dates and who did what | Launch day itself |
| After evidence | The same metrics and screenshots as the before set, taken the same way | Two to four weeks post-launch |
| Retrospective summary | What went wrong, what was fixed, what the team would repeat | The retrospective meeting, exported as written |
Notice the pair in the middle: before and after evidence captured the same way is what converts a portfolio claim into a comparison a client can verify. A claim that the new site is faster means little; the same Lighthouse score run on both sites, side by side, means a great deal, and it costs ten minutes during the two capture windows.
What To Do When The Client Owns The Systems
Most launch evidence lives in systems the client controls — their analytics, their hosting dashboards, their ticket tracker — and access to those systems is exactly what expires after the engagement ends. The capture habit therefore includes a permissions conversation at kickoff, not at launch: the contract or onboarding notes should grant the freelancer the right to export their own working evidence, and the sensible reading of that clause is a standing habit of saving local copies of anything that will later serve as proof. This is not about taking client data; it is about keeping the record of the work itself — screenshots of dashboards, exported reports, the correspondence that recorded decisions. Freelancers uncomfortable asking for this up front discover the cost of skipping it at proposal time, when the client has changed analytics platforms and the old numbers are simply gone. Ten minutes of slightly awkward contract language at kickoff replaces months of archaeology later, and it signals exactly the professionalism the evidence is meant to demonstrate.
The Capture Habit That Makes It Effortless
The system fails if it lives in intention, so it gets a container. Create one folder per client at signing — the same place the contract lives — with the six artifact names as subfolders. The marginal cost of saving something into the right subfolder at the moment it exists is near zero, which is the entire design principle. Two practices keep the container honest. First, capture is a checklist item on the launch plan itself, with a named owner, so it is not the thing sacrificed when launch week compresses. Second, the after-evidence capture has a calendar appointment at go-live plus three weeks, because the post-launch window is exactly when everyone has moved on and the metrics are about to become unrecoverable. Freelancers who run this container for a year end up with a portfolio that assembles itself: every launch leaves six files behind, and proposal season becomes curation instead of archaeology.
From Evidence To Portfolio Story
Raw artifacts are not yet a portfolio — the transformation is selection and framing, and it is quick when the material is good. For a given prospect, choose one launch, open its six folders, and let the case study structure from the site template drive the selection: the before and after evidence carries the results section, the build proof carries the craft section, and the retrospective summary carries the credibility section, because a freelancer who can say what went wrong converts better than one who only narrates success. The definition and launch record rarely appear directly — they exist to keep the story honest when memory and artifacts disagree. The deeper point for portfolio builders: evaluators are not buying Drupal skills, which they cannot verify from the outside; they are buying evidence of a repeatable process, which six artifacts per launch demonstrate better than any superlative. Process proof is what handoff evidence actually is, and it can only be manufactured during the launch, never after it.
The whole system reduces to one sentence: save it when it happens. The hour it costs across a launch is repaid at every future proposal, and the launches themselves run better for being watched by a portfolio-shaped eye.