A Drupal portfolio has one job: convince a skeptical client, in under two minutes, that you can deliver their project without drama. Everything else — the animations, the skill-cloud widgets, the ten-year archive of every site you touched — is decoration that either serves that job or competes with it. Developers who understand this build small portfolios that win briefs; developers who do not build impressive portfolios that lose to quieter ones.
This page is the structure reference. It defines the five sections a Drupal portfolio actually needs, the order that carries a client from “who are you” to “let’s talk”, and the credibility mistakes that quietly disqualify otherwise strong candidates. For the writing layer — how to turn each project into a narrative — follow with the Drupal case study template; for evidence capture habits, the printable case study evidence sheet is the operational companion.
The Five Sections That Matter
Selected work comes first and does most of the work. Three to five projects, each naming the client’s problem, your specific role, the Drupal-specific challenge, and the measurable outcome. “Rebuilt the donation flow on a Drupal 9 site, cutting checkout abandonment by a third” outperforms any superlative. Resist the urge to list everything: the client is hiring your judgement, and curation is the first place that judgement is visible.
Your role, stated plainly. Teams build most real Drupal sites, and clients know it. “Lead developer, responsible for content modeling and migration” builds trust; implying you solo-built a forty-person agency project destroys it the moment a reference call happens. Specificity reads as confidence; vagueness reads as inflation.
Process signals. A short paragraph or three bullet-free sentences on how you work — discovery, content modeling, staged delivery, launch discipline — tells the client what hiring you feels like. Drupal clients have usually been burned by at least one project; process is the antidote they are scanning for.
Proof of craft. One depth piece: a case study that shows your thinking, a before-and-after walkthrough in the style of our before-and-after Drupal portfolio page, or a technical write-up. This is the section other developers read, and it matters because clients increasingly forward portfolios to a technical friend for a sniff test.
A human footer. Availability, timezone, and how to start a conversation. Portfolios lose briefs at the contact step more often than at any other; make reaching you a one-line decision, not a form with twelve fields.
The Drupal Portfolio Section Order
| Order | Section | Question it answers for the client |
|---|---|---|
| 1 | Selected work | Can this person do what I need done? |
| 2 | Your role | Can I trust how they describe their contribution? |
| 3 | Process signals | What will working with them feel like? |
| 4 | Proof of craft | Will they survive scrutiny by my technical friend? |
| 5 | Human footer | Is starting a conversation easy right now? |
The order is a conversion argument, not a taste decision. Clients arrive asking “can you do this”, and the table answers in the sequence their doubts actually arise. Portfolios that lead with biography force the client to hold their first question unanswered while reading about your university years; portfolios that bury contact details behind a project archive answer every question except the one that pays you.
Adapting The Structure To Different Audiences
The five sections survive translation across the three clients Drupal freelancers actually serve. An agency hiring a subcontractor weights process signals and role honesty most heavily — they are buying reliability, not a portfolio star. A direct client with an existing site weights selected work and the human footer — they want evidence you have solved their kind of problem and a conversation that starts without procurement theatre. A technical hiring manager weights the proof-of-craft section almost exclusively and forgives plain design if the depth piece shows real thinking. One structure, three emphases: the sections stay, the proportions move.
This is also where the portfolio-as-asset argument lands. A structured portfolio is not a static page but a reusable briefing artifact: the same five sections answer an RFP’s capability questions, populate a profile on a marketplace, and structure the walkthrough in a first call. Developers who maintain the sections once and reuse them everywhere answer opportunities in hours; developers who rebuild their case for every brief eventually start declining opportunities for lack of time.
Credibility Mistakes That Quietly Cost Briefs
Four mistakes recur across weak Drupal portfolios. The showcase graveyard: twenty projects with no curation, where the client assumes the three good ones are accidents. The team-project inflation described above, where “we” quietly becomes “I”. The screenshot without story — a gallery of homepages tells the client nothing about problems solved, and problems solved are the only currency portfolios trade in. And the stale portfolio: a “recent work” section untouched for three years signals either inactivity or indifference, and clients cannot tell which.
Maintenance deserves one structural note as well. A portfolio that shows only launches quietly tells clients you disappear after go-live; one that includes a maintenance or iteration story — a performance fix, a content-model extension, a long-running support engagement — signals the opposite. The section order does not change; the selected work simply includes one project chosen for its second year rather than its launch week.
One boundary deserves explicit mention: confidentiality. Not every project can be shown, and NDAs are real. The professional move is not to break them but to abstract them — “a national retailer, under NDA; the engagement focused on migration planning” — which demonstrates both the caliber of your clients and your discretion in one line. The Drupal case studies collection shows the pattern applied across engagement types, and the broader Drupal project’s own showcase culture at drupal.org is a useful calibration for what the ecosystem considers a credible case presentation.