I've had founders show me three different design studios' portfolios on a call, all open in browser tabs, all genuinely beautiful. They wanted to know which one was actually good. Honestly, from screenshots alone, you often can't tell, and that's not a knock on their judgment. It's a real limitation of how portfolios get built.
Portfolios are curated by design. A studio shows its best three or four projects, shot and cropped to look their best, usually with the messiest parts of the actual working relationship left out entirely. That's normal, not dishonest. But it means evaluating a web design studio on portfolio screenshots alone tells you about their taste, and almost nothing about how a project with you would actually go.
Why a portfolio alone doesn't tell you what you need to know
A homepage screenshot shows you a finished result, not the decisions behind it. It doesn't show you how many revision rounds it took, whether the client's actual content fit the design cleanly or had to be trimmed to fit, or how the site performs once you're not looking at a hero image but scrolling through a real page on a phone with a mediocre connection.
It also doesn't show you anything about process: how the studio figures out what a business actually needs before designing anything, how feedback gets incorporated, or what happens once the design is approved and someone has to actually build the thing. A gorgeous mockup and a gorgeous, working website are related but not the same deliverable.
What to actually look for in the portfolio itself
Look past the hero shot. Click through to an interior page, ideally one buried a level or two into the site, not just the homepage. If a portfolio only ever shows homepage screenshots, that's worth noticing.
Look for variety in constraint, not just variety in visual style. A studio that's only ever designed sleek portfolio sites for other designers is a different bet than one that's also designed something with real operational complexity behind it, like a booking flow, a dashboard, or a content-heavy site that needed real information architecture, not just a striking layout.
Ask, if it's not obvious, whether the visible project actually shipped and is still live, or whether it's a concept piece never built for a real client. Both have a place in a portfolio, but they answer different questions, and a studio should be upfront about which is which.
The process questions a portfolio can't answer
This is where most of the useful information actually lives, and where a portfolio review needs to turn into an actual conversation.
Ask what the first few weeks of a project look like before any visual design starts. A studio with a real process should be able to describe discovery, research, or scoping steps specifically, not just "we'll have a kickoff call."
Ask how many rounds of design revision are included, and what happens if you need more. Vague answers here tend to turn into scope disputes later. Ask what a design handoff to development actually looks like, and whether the same people doing the design are also building it, or whether it moves to a different team you haven't met yet.
And ask directly what happens after launch. Who fixes something if it breaks. Who owns the design files and the code. These are unglamorous questions, but they're exactly the ones a beautiful portfolio never answers.
Red flags worth taking seriously
A studio that can't describe its process beyond "we're creative" is a flag. So is a studio that won't show you any work beyond a curated homepage carousel, or that gets vague when you ask who specifically works on your project.
Pay attention, too, to whether design and technical execution seem to live in completely separate conversations. A studio focused entirely on visual craft that has nothing to say about how the site will actually perform, load, or get found in search is telling you something about what happens after the design gets approved.
What a real creative process looks like
My own process starts with a scoping conversation, not a mood board: what the business actually needs the site to do, who's visiting it, and what's already working or not. From there I design in Figma, usually with wireframes first so structure gets agreed before visual polish does, then move into full interface design with your actual content, not placeholder text.
Development happens after design is approved, built in React or Next.js with the same attention to Core Web Vitals and search structure that goes into the visual design, because a beautiful site that loads slowly or can't be found on Google hasn't actually solved the business problem. Editable design files and full source code ownership transfer to the client at the end, no exceptions.
If you're comparing studios right now, it's worth asking every one of them the process questions above, not just admiring their tab full of screenshots. If you want to see how that conversation would actually go with me, start with a look at the design process itself, or reach out directly with what you're trying to build.