You can judge a developer's portfolio without reading a line of code. Open each project and use it, check that it lives at a permanent address and has been updated recently, find out which parts the developer built themselves, and ask them to walk you through one decision they made. Those four checks catch most weak portfolios.
Non-technical clients often feel they have to take a portfolio on trust, or pay someone technical to look at it. Neither is true. A shipped product is evidence anyone can examine, the same way you can judge a restaurant without being a chef. What follows is how to do it in about twenty minutes per developer.
Use the product for ten minutes
Do what a real user would do, and then a little more:
- Sign up, or start the main task. Is it obvious what to do first?
- Do something wrong on purpose. Leave a required field empty. Type letters into a number field. Click "forgot password". Error messages and empty screens are where care shows, because nobody puts them in a screenshot.
- Open it on your phone. A layout that breaks on a phone means nobody looked.
- Come back later. Close it and reopen it. Are you still logged in? Is your data still there?
- If it charges money, look at the pricing and checkout. Someone who has built working payments has handled real edge cases.
You are not grading the idea or the design taste. You are looking for signs that someone finished the work properly, including the parts users rarely see.
Check that it is real and alive
| What you see | What it tells you |
|---|---|
| Its own domain, or an App Store / Google Play listing | A permanent home. Someone committed to it. |
| A temporary preview link (a subdomain of a hosting service) | Possibly a demo that was never launched. Ask. |
| A store listing updated in the last year | The app has been maintained, not just launched. |
| A changelog, blog or release notes with dates | A trail of work over time. |
| Working sign-up, email and payment | The unglamorous parts were built, not faked. |
| Links that 404, or "coming soon" for months | The project stopped. Not disqualifying, but ask what happened. |
Find out what they actually built
Many portfolio projects were team efforts. That is normal, but you need to know which part was theirs.
Ask directly: "Which parts of this did you build yourself, and who did the rest?"
A good answer is specific and a little boring: "I did the app and the API, a designer did the screens, and the client's team handles the website." A vague answer ("we built the whole thing") for a project that obviously needed several people is worth a follow-up question.
For apps, the store listing helps. The developer or company name on the listing shows whose account published it. For open-source work, a developer's public profile on GitHub or similar shows their own contributions with dates.
Ask for a walkthrough of one decision
This is the most useful five minutes of any conversation with a developer:
"Pick one project and show me something you would build differently if you started again."
You do not need to understand the technical detail of the answer. Listen for the shape of it:
- Good: a specific decision, why they made it at the time, what they learned, what they would do now. "I stored everything in one table to launch quickly. It worked, but adding teams later meant a painful migration."
- Weak: "Nothing, it is perfect", or a list of technologies with no reasoning.
People who have shipped and maintained real things always have an answer to this question, because maintaining software means living with your own past choices.
What not to judge on
- The number of projects. In our own count of 46 builders, the median listed exactly one project (what independent developers are actually shipping). One real, maintained product is stronger evidence than ten tutorial clones.
- A long skills list. Anyone can type a technology into a profile. In what freelance developers list as their skills, we found people listing stacks they had not shipped anything in. Trust what the projects show.
- Polish, if you are hiring for something else. A backend developer's own site may look plain. Judge the work you are hiring them for.
- Popularity. Stars, followers and download counts measure marketing as much as skill.
Red flags specific to portfolios
- Screenshots with no links. Anyone can make a screenshot. Ask for something you can open.
- Everything is "under NDA". Some client work genuinely is. But a developer with years of experience can usually show at least one thing. If they cannot, that is a gap.
- The same project on several people's profiles, each claiming it. Ask each what they did.
- Templates presented as custom work. If several portfolio sites look identical apart from the name, ask what was built from scratch.
More general warning signs are in freelance developer red flags.
Why this works
A portfolio of shipped work is the one thing in hiring that a non-technical person can check directly. It cannot be rehearsed like an interview or polished like a CV. On Shipfolks every profile leads with products you can open, and each listing is reviewed by a person before it goes up. That review checks that the thing is real and at a permanent address, not that it is good. Judging whether it is good is the twenty minutes above, and they are yours to spend. You can browse builders who are open to work and start with whichever project you would actually use.