Most case studies on developer portfolios are marketing brochures dressed up in a grid. Big hero image, two paragraphs of "the client wanted a modern website", a screenshot of the homepage, and a link to the live site. That is not a case study. That is a screenshot with a caption.
A real case study is a piece of evidence. It is a developer telling you, on the record, what problem they were given, what they decided to do about it, and what actually happened after the site went live. If you cannot answer those three questions after reading one, the case study is not doing its job.
This post is about how to read them, what signals matter, what to ignore, and how to use case studies to decide whether a developer can actually deliver for your business.
What a case study is supposed to do for the reader
When you land on a case study as a potential client, you are asking one question: can this person solve my problem?
You are not there to admire typography. You are there to verify that the developer has shipped something similar to what you need, that they understood why they were building it, and that the result is real enough to point at.
A good case study answers four things in order:
- What was the situation before? What did the client have, and why was it not working?
- What did the developer change, and why? Specific decisions, not vague aesthetic claims.
- What is the live result? A working site you can open and use yourself.
- What changed for the business after? Numbers, behaviour shifts, or, if the project is too new, a clear note saying so.
If a case study skips two of these four, it is selling, not informing. You can read 50 of them on agency sites tomorrow and confirm this for yourself.
The headline metric, and how to spot a fake one
Most case studies open with a big number. "Conversions up 240%". "Page speed improved by 4x". "60% reduction in bounce rate". These are designed to grab you. They also lie more often than people admit.
Here is the test for a real metric:
- Is the baseline shown? "Conversions up 240%" is meaningless if the previous number was three sales a month. Honest case studies show the before figure too.
- Is the time window stated? Six weeks vs six months tells you wildly different things. A metric with no time window is decorative.
- Is it tied to a specific change? "Page speed went from a Lighthouse score of 41 to 96 after the migration off WordPress" is a real claim. "Performance improved" is not.
- Could you replicate the measurement? If a developer claims "200% more leads", you should be able to imagine where that number came from, a CRM, a form-submission count, a tagged event. If the source is mysterious, the number probably is too.
You will see numbers like "+340% engagement" everywhere on agency sites. Engagement is one of the easiest metrics to game, it can mean time on page, scroll depth, page views per session, anything. Treat unspecified percentages with deep suspicion.
The approach section is where you find out if they think
The middle of a case study, the part most people skim, is actually the most important part. It is the section where the developer explains what they decided and why.
This is where you find out whether you are dealing with someone who thinks about your problem, or someone who applies the same template to every project.
Real approach sections sound like this:
"The previous site was a WordPress install on shared hosting with 14 plugins. Mobile Lighthouse score was 38. We rebuilt on Next.js, kept the visual identity, dropped the plugins in favour of three Server Components, and moved hosting to Vercel."
That is a sequence of decisions. You can argue with each one. You can imagine the trade-offs. You can tell that someone actually looked at the previous site and made choices.
Generic approach sections sound like this:
"We crafted a bold, modern website that elevates the brand and creates a memorable user experience."
This sentence could describe literally any project. It tells you nothing. If the entire case study reads like that, the developer either did not make any decisions worth talking about, or, more commonly, they did not write the case study and have no idea what was actually shipped. Both are bad signs.
I cover the underlying process in From Design to Deployment, How I Build Websites, but the short version is: every project should produce a small list of specific decisions that can be defended in writing. If a case study cannot list them, the developer did not make them.
The "live site" test, do this before you read another word
Before you finish reading a case study, open the live site they are pointing at. On your phone, on cellular if possible, with the case study still open in another tab.
Then run the following five-second checks:
- Does it load before you can count to three? Slow sites kill businesses. I wrote about why in What Makes a Website Fast and Why It Matters.
- Does the mobile layout actually work, or is it a squished desktop? Tap around. Try the menu. Try the contact form.
- Is the page in front of you doing the job the case study claims? If the case study says "designed to drive bookings", look for the booking call-to-action. Is it visible without scrolling? Is it obvious what to do?
- Does the site exist at all? I am not joking, agency sites regularly link to case studies for clients that have since rebuilt or shut down. A "case study" pointing at a now-defunct site is a portfolio piece, not evidence.
If the live site does not pass these basic checks, the case study is decorative. It does not matter how beautifully the case study itself is presented.
Screenshots are not the proof, they are the illustration
A surprising number of case studies are 80% screenshot collage and 20% text. The screenshots look professional. The site they are showing might be excellent. But screenshots prove almost nothing.
Why? Because:
- A screenshot can be staged. Designers regularly clean up demo content, hide imperfect sections, and shoot at unusually wide viewports to make work look more polished than what the user actually sees.
- A screenshot does not test. Speed, interaction, and accessibility are invisible in a static image. The site could score 12 on mobile and the screenshot would still look great.
- A screenshot does not contextualise. A beautiful product card means nothing without knowing how the user got there, what they were trying to do, and what happened next.
Use screenshots as visual confirmation that a site exists and looks like the case study claims. Do not let them substitute for the parts of the case study that actually matter, decisions, results, and the live link.
What good case studies tell you about the developer themselves
You can learn as much about a developer from how they write their case studies as from the projects in them. Read three or four in a row and watch for:
- Do they talk about constraints? Real projects have budget limits, timeline pressure, awkward existing systems. A developer who never mentions any of these has either never worked on a real client project, or sanded all of them out for marketing reasons.
- Do they admit trade-offs? "We chose Next.js over a static generator because the client needed a CMS, even though it adds hosting cost" is a sentence that should appear somewhere. A case study where every decision is portrayed as obviously correct is pretending.
- Do they credit the client? A site is a collaboration. If every case study is written as a solo hero narrative, the developer probably treats clients that way too.
- Do they sound like a human? Case studies written by an actual builder have texture, frustrations, surprises, "this is the part I would do differently next time". Case studies written by a marketing department all sound the same. You can feel the difference inside two paragraphs.
This is one of the best signals you have, and it is free. Most clients ignore it.
Industry-specific case studies matter more than total count
Three case studies in your exact industry are worth ten case studies in unrelated ones. Tourism, e-commerce, professional services, restaurants, real estate, these are not interchangeable. The patterns that work for booking guests do not transfer to selling industrial equipment, and vice versa.
If you are a tourism business in Croatia, for example, look for evidence that the developer has actually shipped tourism work, and that they understand the specific problems of the field. I covered the patterns I have seen in Tourism Websites in Croatia: What Actually Books Guests, and most of them are invisible to a developer who has only built corporate sites.
The same goes for e-commerce, multilingual sites, and accessibility work. Domain experience is the difference between a developer who reinvents your category from scratch and one who walks in already knowing what is going to bite you.
Red flags in case studies
A short list of things that should make you close the tab:
- No live link. If the site is not currently online, the case study is making claims you cannot verify.
- Stock client photography on a "results" page. A real case study uses real client material or no people at all. Stock smiling office worker = marketing.
- Vague metrics with no baseline or time window. "More leads", "huge improvement", "exceptional results".
- The same case study structure for every project, with the words swapped. This is templated content marketing, not real reflection.
- Testimonials with first names only ("Sarah, Marketing Manager"). A real testimonial has the full name, the company, and ideally a link. Anything less should be treated as fictional until proven otherwise.
- Heavy use of words like "synergy", "innovative", "cutting-edge", "best-in-class". These are signals of marketing-team authorship, not builder authorship.
- No mention of what was hard. Every project has hard parts. A case study with no struggle is a fairy tale.
You will not find a case study that avoids every one of these. You should worry when a portfolio's case studies all share three or four of them.
What you should do with case studies you trust
Once you find a case study that passes these tests, real metrics, defensible decisions, a working live site, honest writing, use it as a starting point for the conversation, not the end of it.
Bring up specific things from the case study when you talk to the developer. Ask why they made decision X. Ask what they would do differently. Ask whether the constraints in your project look more or less painful than the ones in that one.
A developer who can talk fluently about their own published case studies is almost always a developer who actually did the work. A developer who fumbles when you reference their own portfolio is almost always a developer whose marketing team writes their case studies.
That conversation, more than any portfolio page, is what tells you whether you should hire someone. The case study just gets you to the point where the conversation is worth having.
If you are early in the hiring process, What to Look for When Hiring a Web Developer covers the rest of the evaluation, process, deliverables, communication, what happens after launch. Case studies are one piece of evidence. Treat them like one.