How to Evaluate a Developer's Portfolio When You're Not Technical

You don't need to read code to evaluate a developer. As a non-technical buyer you can check most of what matters yourself: whether their past work exists and runs today, exactly which part of it they built, and whether their clients will vouch for them. The one thing you can't judge, the code itself, you can pay another developer to review.

I'm a freelance developer based in Denmark, so I sit on the other side of this table. Read it with that bias in mind. It's also exactly what I'd do if I had to hire a developer without being able to read their code.

The short answer: what you can check without technical skills

There are five things worth judging in a developer's portfolio. Four of them need no technical knowledge at all, just time and the right questions.

The portfolio review is one step in a longer process. For the whole sequence, from writing a brief to signing a contract, see my step-by-step guide to hiring a developer.

Step 1: Pick out the projects that look like yours

Most portfolios are built to impress everyone. You only need the projects that say something about your job, so pick two or three and set the rest aside for now.

Similarity is about the kind of product, not the industry. Say you need a customer portal with user accounts and a Stripe or Xero integration. Another portal with logins and payments is relevant even if it was built for a logistics firm and you run a clinic. A beautiful marketing site from your own sector tells you far less.

Run each candidate project through four questions:

1. Is it the same kind of thing: a website, an online store, a web app, a SaaS product or an internal tool?
2. Does it share the hard parts of yours, like user accounts, payments, integrations with other systems or lots of simultaneous users?
3. Is it roughly the same size, or a weekend project next to yours?
4. Is it still running, or was it a one-off delivery?

If nothing resembles your project, ask whether there's relevant work that isn't on display. A lot of B2B development sits behind a login or under an NDA, so a thin public portfolio isn't automatically a bad sign.

Be honest about what the portfolio shows, too. If every project was built by one person and you need design, copywriting, development and project management at the same time, a solo contractor may be the wrong fit however good the work looks. That includes me.

Step 2: Use the live work yourself

This is where your time pays off most. You don't need to know how something was built to tell whether it works.

Websites and online stores

Open each link on your phone and on a laptop. Click around, use the search, submit a form, put something in the cart. You're checking three things: whether it matches what the portfolio claims, whether anything breaks, and whether it feels fast.

For speed, run the address through Google's free PageSpeed Insights and see whether the result comes back green, orange or red. Treat it as a rough signal rather than a grade. Google itself notes that the score changes from run to run, and a slow page can be down to the client's oversized images or marketing scripts rather than the developer's work.

To see whether a site has been looked after since launch, look it up in the Wayback Machine, which keeps snapshots of websites over time. You'll get a rough launch date and a sense of whether it has kept evolving.

Products behind a login

The most telling work is often the part you can't see: customer portals, internal tools, admin dashboards and SaaS products. You have two options. Sign up for a trial if the product offers one, or ask the developer for a short screen-share walkthrough.

The walkthrough is the best test you have. Ask them to show you around as if you'd just joined the team: what problem did the client have, what does the product do, and which part was hardest to build? Someone who really built it can answer without notes and explain it in plain English.

If you're in the EU or UK and the product handles personal data, add one question: where was the data hosted, and who had access to it? You're not looking for a GDPR lecture, just a clear, specific answer that shows they thought about it.

Mobile apps and projects that no longer exist

For a mobile app, the App Store or Google Play listing shows when it was last updated and what users say in the reviews. If a project has been shut down, ask why. Products close for all sorts of reasons, often commercial ones. Listen to the explanation, not to the fact that it's gone.

Step 3: Pin down what they built themselves

This is the most important step, and the one many buyers skip. Almost every product of any size has several people behind it: a designer, one or more developers, maybe an agency with a project manager. If the developer used to work at an agency, their portfolio may well show agency projects. That's fine, as long as you know which part was theirs.

Keep in mind that the polished look usually belongs to the designer. A developer's work shows in what works: logins, payments and integrations that don't fail, pages that load quickly, and a product that's still running a few years later.

For each project on your shortlist, ask:

1. What did you build yourself, and what did others do?
2. Were you there from the start, or did you join later?
3. Who talked to the client and made the decisions?
4. What was the hardest part, and how did you solve it?
5. Who maintains it today?

A good answer is specific and slightly boring: "The agency did the design. I built the backend and the inventory integration, and for the last eight months I was the only developer on it." A warning sign is a role that gets vaguer the more you ask, or a "we" that never turns into an "I".

For the rest of that conversation, I've put together 27 questions to ask a developer before hiring.

Step 4: Read the testimonials like a skeptic

Testimonials on a developer's own site are picked by the developer, so they're never negative. That doesn't make them worthless, but read them with a few questions in mind:

• Is there a full name, company and job title? A quote from "Sarah, CEO" can't be checked.
• Can you find the person on LinkedIn, and did they work at that company at the time?
• Does the quote mention something concrete, like deadlines met or an integration that works, or is it general praise?
• Do the testimonials match the projects in the portfolio?

Reviews on platforms like Clutch or Upwork, and LinkedIn recommendations, help you spot patterns. They're short, though, and rarely say how problems were handled.

The strongest move is to talk to one or two clients yourself, ideally from the projects that resemble yours. Fifteen minutes on the phone beats a page of quotes because you can ask follow-up questions and hear where they hesitate. I've written up nine questions to ask a developer's past clients for exactly that call.

Step 5: Ask for what you can't see

After going through the portfolio you'll usually have a few gaps. Maybe the most relevant project sits behind a login, or you're unsure what's going on under the surface. Here's what you can reasonably ask for:

• A walkthrough of a relevant project behind a login, by screen share or with a test account.
• An introduction to a client from a project like yours.
• A short written summary of one project: the problem, the solution and the developer's role.
• A code sample, or read access to a repository (where the code is stored), that another developer can review.

Only the last one tells you anything about the code itself. You can't read it, and you don't need to. An independent developer can usually give you a view within a few hours on whether the code is organized, tested and easy to build on. That's worth paying for when the budget is large, when the product is business-critical or when you're taking over an existing codebase. I cover when it pays off in when to get an external code review.

If you're still unsure after all that, the safest test is to work together on something small. A paid trial project shows how the developer works with you, on your problem, and no portfolio can do that.

Red flags and false alarms

Some things in a portfolio should make you stop. Others look suspicious but are perfectly normal.

Red flags

• Only screenshots and design mockups, with no links to anything live.
• Links that are broken, or that lead somewhere different from what the screenshots show.
• A role the developer can't explain, or one that changes when you ask again.
• Testimonials with no names, or names you can't find anywhere.
• Every project looks like the same off-the-shelf template, when what you need is custom-built.

False alarms

• Few public projects. Much B2B work lives behind logins or NDAs.
• A portfolio that hasn't been updated in a while. Busy developers are often the worst at maintaining their own site.
• Nothing from your industry. The type of product matters more.
• A quiet GitHub profile. Client code usually lives in private repositories nobody outside can see.

For warning signs across the whole process, from the first email to the contract, see red flags when hiring a developer.

Next steps: from portfolio to first call

Once you've worked through the portfolios, you should have one to three candidates left and a list of questions for each. Run through this checklist before moving on to interviews and reference calls.

If I'm on your shortlist, here's what I build and how working with me is set up. You own the code from day one, and larger builds start with a paid, fixed-price discovery phase.

Frequently asked questions

What if the developer doesn't have a portfolio?+

Ask why before you rule them out. Developers coming from a salaried job, or whose work is covered by NDAs, can be very good without a public portfolio. Ask for a screen-share of something they built, or a personal project. If they can't show, describe or point to anything at all, start with a small, paid, fixed-price task before you trust them with something big.

Do big-name clients in a portfolio mean anything?+

Less than you'd think. A famous logo shows the developer worked on something for that company, not what they did. Large companies buy small jobs too, and the work might have been one form on a huge site. Ask about role and scope just as you would for any other project. A smaller project the developer owned end to end often tells you more.

Can I use AI to review a developer's code?+

Only to prepare, not to decide. An AI assistant can explain what a piece of code does and flag obvious problems. But it doesn't know the project's history or requirements, and you can't tell whether its answer is right. Use it to come up with questions for the developer. And never paste in code from a client project without permission from both the developer and the client.

How long should evaluating a portfolio take?+

My rule of thumb is an hour or two per candidate, once you've filtered out the obvious mismatches. That covers two or three relevant projects, a walkthrough or conversation about their role, and one client call. It sounds like a lot, but it's small next to a project that may run for months. Save that time for the candidates still in the running after a first call.