A Drupal case study on a portfolio site has one job: let a skeptical client verify that you have solved their kind of problem before. Not that you can build websites in general — that you have untangled a migration with twelve thousand nodes, or untangled editorial permissions for a newsroom, or rescued a site that a previous vendor abandoned. Generic case studies (“we delivered a modern, responsive solution”) verify nothing. This guide shows how to structure Drupal case studies that carry evidence, and how many you actually need.
Three Case Studies Beat Ten
A portfolio does not need volume; it needs coverage of the situations clients actually fear. Pick three project types and write one strong case study for each. A good spread for a Drupal freelancer: a rebuild or migration with real numbers, an editorial workflow or permissions problem, and a long-term maintenance relationship with visible before-and-after health metrics. Almost every prospect inquiry maps to one of these three fears — “my last developer left,” “my editors can’t publish without breaking things,” “my site is old and I’m afraid to touch it.” When a prospect sees their exact situation named, the case study has done its work, and three is enough to make that happen on most portfolios.
The Structure That Carries Evidence
Every case study on the portfolio answers the same six questions, in the same order, so a scanning client can find the proof fast. The situation: what the site and team looked like before you arrived. The constraint: the thing that made it hard — budget, deadline, legacy data, a nervous stakeholder. Your role: what you specifically did, named concretely (“migrated 12,400 nodes with a custom migration plugin and reconciled the taxonomy in the process”). The numbers: anything countable — load time, editor hours saved, bounce rate, launch date held. The human part: what the client said they could now do that they couldn’t before. And the artifact: a screenshot, a diagram, or a short quote that a reader can verify with their own eyes.
| Section | Weak version | Evidence-carrying version |
|---|---|---|
| Situation | The client needed a modern website | A 2017 Drupal 7 site with 40 content types, three unused themes, and no one on staff who could log in safely |
| Constraint | Tight deadline and high expectations | Migration had to finish before the hosting contract expired, with zero downtime on a site taking donations nightly |
| Your role | Led the project end to end | Wrote the migration, rebuilt the two used content types, trained four editors, deleted the other 38 with the client’s sign-off |
| Numbers | Improved performance significantly | Homepage load time from 6.2s to 1.4s; editor publishing errors down to zero in the first month |
| Human part | The client was very happy | The office manager now publishes the monthly newsletter herself without opening a support ticket |
| Artifact | Screenshot of the new homepage | Before/after performance chart plus a one-line quote from the client with their name and role |
Drupal Case Studies Case Study Evidence Card
This evidence card is the pre-flight check before a case study goes live. Fill one card per case study; if a cell resists being filled, the case study is not ready, and that is fine — better to publish three complete stories than six half ones.
| Card field | What belongs here | Done when |
|---|---|---|
| Client context | Sector, site size, team size — anonymized if needed | A reader can tell if their project resembles this one |
| Drupal specifics | Version, notable modules, hosting, integration points | Another Drupal developer could assess the work from this alone |
| Measurable outcome | At least one number that changed | The number has a source and a date, even if only visible to you |
| Named artifact | Screenshot, chart, diagram, or dated quote | The artifact is your own work product, not stock imagery |
| Client permission | Written OK to publish, or anonymized consistently | No cell leaks a name the client did not approve |
Three Mistakes That Quietly Weaken Case Studies
The first mistake is writing about the technology instead of the problem. Clients do not buy “Paragraphs with Layout Builder and a decoupled preview”; they buy “our editors stopped breaking the homepage.” Name the Drupal pieces precisely enough for a technical evaluator to trust you, but lead every section with the business sentence. A good test: read the case study aloud to a non-technical friend. If they stop you to ask what something means, that sentence is for a different document.
The second mistake is smoothing over the constraint. A case study with no difficulty in it reads as fiction. The stalled migration, the stakeholder who vetoed the design twice, the hosting bill that doubled under load — these are exactly the details that make the outcome believable, because the reader has the same difficulties waiting at home. The third mistake is letting numbers float without context. “Load time improved 78%” means little alone; “from 6.2 seconds on the donation page to 1.4, measured the week after launch” is a claim a reader can hold you to, which is precisely why it builds trust.
Permission, Anonymization, And The Ones You Cannot Publish
The hardest part of portfolio case studies is rarely the writing; it is permission. Some clients will not be named, some NDAs forbid specifics, and some of your best work is invisible by nature — a security fix you cannot describe is a case study you cannot write. Handle this with a consistent anonymization convention: “a European nonprofit,” “a regional healthcare network.” What must survive anonymization is the shape of the problem and the numbers, not the logo. When even that is impossible, write the lesson instead: “what a migration with 40 content types taught me about deletion” carries nearly as much trust as the named story, and it never violates a confidence.
One more habit separates strong portfolios: retire case studies that no longer represent your work. A study from five years and two major Drupal versions ago teaches prospects to expect the old you. Keep the portfolio small, current, and evidence-dense — the before/after portfolio page walkthrough on this site covers the page-level layout that holds these studies, and Drupal’s own case studies section shows the community standard for evidence-backed project stories. Review the whole set twice a year against the evidence card, and let anything that fails the card come down quietly.